У нас есть длинные сборки, на которые мы обычно планируем наши задания cron, но иногда нам приходится повторно запускать сборку в нестандартные временные рамки, и мы можем столкнуться с конфликтами с заданиями cron, которые обычно безопасно запускать в это время.
У нас есть несколько учетных записей, которые запускают как сборки, так и задания cron, поэтому мы не можем приостановить службу crontab для всей машины, а затем перезапустить ее позже.
Мне было интересно, есть ли у кого-нибудь шаблон или реализация. Я представляю, как это работает
Пользователь создает файл: ~ / block-crontab
Пользователь запускает сборку. Задание cron ищет этот файл в домашнем каталоге пользователя и, если он есть, просто пропускает все задания cron. В противном случае он запускает задания. Затем, когда сборка завершена, пользователь удаляет ~ / block-crontab
Это сработает? Я предполагаю, что мне нужно как-то изменить скрипт cron. Мне в основном интересно, есть ли лучший / стандартный подход к этой проблеме?
Спасибо.
Вместо того, чтобы возиться с crond, Я настоятельно рекомендую реализовать некоторую (даже простую) форму блокировки внутри ваших сценариев сборки. Например, коснитесь и проверьте наличие файла в /var/run/: если ваш сценарий что-то нашел, значит, проект строит другой процесс. Очевидно, вам нужно удалить файл блокировки, когда закончите.
Как отметил @GnP в комментариях, вы также можете использовать flock утилита для полуавтоматического управления файлами блокировки.
Если вы не используете / не можете полагаться на какой-либо механизм блокировки, простая проблема service crond stop выключить crond система.
Я обычно просто оборачиваю все длительные команды на экране и получаю cron для запуска экрана, только если он еще не запущен.
Итак, следующая строка в crontab
*/2 * * * * /bin/bash /path/to/LongRunningScript.bash
... превращается примерно в это:
*/2 * * * * /usr/bin/screen -S MyUniqueName -Q select . || /usr/bin/screen -dmS MyUniqueName /bin/bash /path/to/LongRunningScript.bash
Мне это нравится, потому что это также дает вам возможность подключиться к запущенному скрипту и проверить его вывод / статус.
В вашем сценарии вы могли бы получить cron чтобы проверить наличие другого экрана перед выполнением сборки, например
0 3 * * * /usr/bin/screen -S ManualBuild -Q select . || /usr/bin/screen -dmS AutomatedBuild /bin/bash /path/to/BuildScripts.bash
10 3 * * * /usr/bin/screen -S ManualBuild -Q select . || /usr/bin/screen -dmS OtherAutomatedBuild /bin/bash /path/to/OtherBuildScripts.bash
Когда вы запускаете сборку вручную, просто перейдите в screen сначала перед запуском скрипта (прокомментируйте, если вам нужны подсказки, как подключиться / отключиться от screen. Это полезная утилита - попробуйте, если вы еще не начали ее использовать)
Тип screen -S ManualBuild, ударить [enter] и запустите любые команды, которые хотите запустить.
Примечание. Если вы используете приведенный пример, вы можете запутать cron если у вас более 1 сеанса работы с экраном с именем «ManualBuild».