Как лучше всего настроить задание cron, чтобы проверить, что длительный процесс все еще идет, и если нет, запустить его?
Согласно названию:
Как лучше всего настроить задание cron, чтобы проверить, что длительный процесс все еще идет, и если нет, запустить его?
Если я начну длительный процесс в cron, он будет блокироваться? или cron развивает процесс как независимый дочерний элемент?
Спасибо!
5 ответов
Как лучше всего настроить задание cron, чтобы проверить, что длительный процесс все еще идет, и если нет, запустить его?
Простой подход состоит в том, чтобы иметь простой скрипт, который проверяет, работает ли процесс или нет, а затем перезапускает его при необходимости.
(Иногда лучше на самом деле проверить, что процесс выполняется с помощью "фиктивной транзакции", например, для проверки процесса SMTP вы можете установить соединение через порт TCP и убедиться, что он отвечает правильно.)
Но следите за различиями в вашей среде между вами, как интерактивным пользователем, и когда cron(8) запускает ваш скрипт.
Чтобы ответить на второй бит вашего вопроса:
Если я начну длительный процесс в cron, он будет блокироваться? или cron развивает процесс как независимый дочерний элемент?
cron(8) разветвляется для выполнения задания cron, но если ваш скрипт или процесс не "отсоединяется", cron будет поддерживать его как дочерний процесс до его завершения (вот как cron может собирать весь вывод из stderr и отправлять его через Эл. адрес.)
Но, думаю, вы подумали, не могли бы вы на самом деле запустить длительный процесс из cron? Если вы сделаете это, вам нужно убедиться, что он может запускать только одну копию самого себя и что он быстро завершится, если он уже запущен.
Более эффективные решения для поддержания работоспособности длительных процессов - если вас беспокоит только выход или сбой
- если ваш процесс можно сделать так, чтобы он оставался подключенным, используйте init(1) через inittab(5) и опцию "respawn". Часто даже у демонов есть опции "без форка".
- Или, если ваша ОС не имеет функции inittab или у вас нет к ней доступа, используйте что-то вроде daemontools от DJB.
- если вы имели роскошь использовать Solaris 10 или OpenSolaris, вы можете использовать SMF. (Это может даже работать с процессами, которые делают fork и detach.)
- Если это ваш собственный код, вы можете написать его, чтобы иметь пару процессов родитель / потомок, где родитель перезапускает дочерний элемент всякий раз, когда он получает SIGCHLD.
Распространенная идиома заключается в том, что для длительного процесса имеется файл pid. В основном файл в /var/run или подобный, у которого только есть pid, или идентификатор процесса программы. Когда программа запускается, она помещает файл туда, а когда она останавливается, она удаляет файл. Вы можете легко проверить, что программа там, видя, есть ли этот файл.
Это также может быть использовано, чтобы увидеть, если программа потерпела крах. Если файл есть, но с этим pid не запущен процесс, то программа остановилась, но не удалила файл pid, то есть произошел сбой. В этом случае вы можете удалить файл pid и перезапустить программу. Однако это не является надежным доказательством, так как иногда PID может повторно использоваться новым процессом, который запускается после сбоя исходного.
Под "длительным запуском" вы подразумеваете что-то, что просто занимает много времени, или демон, который должен работать постоянно?
Если вы имеете в виду процесс, выполнение которого занимает много времени, то, как и было предложено, создайте файл pid и найдите его при запуске. Если файл существует, выведите сообщение и выйдите из него. В противном случае запустите как обычно.
Если вы имеете в виду демон (иногда называемый сервисом), вместо использования cron вам следует взглянуть на ps-watcher, я использую его для того же.
С веб-сайта: "... его можно использовать для обеспечения того, чтобы демон работал или не работал слишком много раз. Он также может использоваться для определения того, когда процесс потребляет слишком много ресурсов, возможно, из-за утечки памяти ".
Вы просто настраиваете ps-watcher для поиска вашего процесса. ps-watcher проверит список процессов и, если он не найден, ps-watcher запустит его для вас.
В зависимости от того, как вы определяете ваш процесс, cronjob может выглядеть
* * * * * pidof исполняемый файл || / USR / местные / бен / исполняемый
при условии, что ваш исполняемый файл представлен как сам по себе в списке процессов. Более разумным способом было бы иметь pid-файл и использовать start-stop-daemon. На самом деле, все зависит от рассматриваемого процесса. Некоторое время назад я также написал для этой цели небольшой демон обслуживания процессов.
И нет, cron не будет блокировать, но, в зависимости от характера вашего процесса, вы все равно можете использовать его в качестве фона.