Утилита flock позволяет удерживать блокировку на время выполнения команды. Если все запуски используют один согласованный путь, можно не допустить их перекрытия. На Mentoring.digital разберём локальную схему для уже существующего скрипта.
Оборачиваем команду в блокировку
В примере скрипт report.sh уже существует, а текущий каталог выбран осознанно. Подготовьте доступный служебный каталог. Этот пример не настраивает cron и не меняет расписание.
mkdir -p .run
flock -n -E 75 .run/report.lock bash ./report.sh-n запрещает ожидание занятой блокировки. С -E 75 конфликт возвращает выбранный код. Без -n обычное поведение состоит в ожидании освобождения блокировки.
Общий путь и код результата
Все участвующие запуски должны использовать один lock-файл. Если планировщик запускает команду из другого каталога, относительный путь может указывать уже на другой файл. Для рабочего запуска согласуйте постоянный доступный путь.
Выбранный код конфликта нужно отличать от кодов самого приложения. Если скрипт тоже возвращает 75, одной цифры недостаточно для определения причины. Проверяйте диагностическое сообщение и правила обработки результата.
Существование lock-файла не показывает, что блокировка сейчас занята. Не удаляйте его автоматически как способ освободить работающую блокировку: другой запуск может открыть новый файл по тому же имени.
Как проверить взаимное исключение
На отдельном учебном сценарии выполните длинную безвредную команду под блокировкой, затем попробуйте второй запуск с тем же путём. После завершения первого проверьте новый успешный запуск. Не используйте для эксперимента рабочую рассылку или платёжный скрипт.
Учитывайте особенности файловой системы: на NFS и SMB поддержка и поведение блокировок могут отличаться или зависеть от настроек. Локальный пример не является подтверждением надёжной распределённой блокировки для любой инфраструктуры.
Командную строку и автоматизацию изучают на курсах DevOps. Разобрать реальные условия запуска поможет наставник по DevOps.
