По названию:
Как лучше всего настроить задание cron, чтобы проверить, что длительный процесс все еще выполняется, а если нет, запустить его?
Если я запустил длительный процесс в cron, он заблокируется? или cron разветвляет процесс как независимый потомок?
Спасибо!
Как лучше всего настроить задание cron, чтобы проверить, что длительный процесс все еще выполняется, а если нет, запустить его?
Простой подход состоит в том, чтобы иметь простой сценарий, который проверяет, запущен процесс или нет, а затем перезапускает его при необходимости.
(Иногда лучше всего проверить, что процесс выполняется, с помощью «фиктивной транзакции», например, для проверки процесса SMTP вы можете установить соединение через порт TCP и проверить, что он отвечает правильно.)
Но следите за различиями в вашей среде между вами как интерактивным пользователем и тем, когда cron (8) запускает ваш скрипт.
Чтобы ответить на вторую часть вашего вопроса:
Если я запустил длительный процесс в cron, он заблокируется? или cron разветвляет процесс как независимый потомок?
cron (8) выполнит форк для выполнения задания cron, но если ваш скрипт или процесс не отсоединятся, cron будет поддерживать его как дочерний процесс до тех пор, пока он не завершится (именно так cron может собирать весь вывод из stderr и отправлять его через Эл. адрес.)
Но, я думаю, вы думали, а можно ли запустить длительный процесс из cron? Если вы это сделаете, вам нужно убедиться, что он может запускать только одну копию самого себя и что он быстро выйдет, если он уже запущен.
Лучшие решения для поддержания продолжительных процессов в рабочем состоянии - если вас беспокоит только выход или сбой
Распространенная идиома - длительный процесс должен иметь файл pid. В основном файл в /var/run или аналогичный, который просто имеет pid или идентификатор процесса программы. Когда программа запускается, она помещает туда файл, когда останавливается, она удаляет файл. Вы можете легко проверить наличие программы, посмотрев, есть ли там этот файл.
Это также можно использовать, чтобы узнать, не завершилась ли программа. Если файл есть, но нет процесса, запущенного с этим pid, значит, программа остановилась, но не удалила файл pid, то есть потерпела крах. В этом случае вы можете удалить файл pid и перезапустить программу. Однако это не является доказательством дурака, поскольку иногда PID может быть повторно использован новым процессом, который начался после того, как ваш исходный отказал.
Под «длительной работой» вы имеете в виду то, что запускается долго, или демон, который должен работать постоянно?
Если вы имеете в виду процесс, который требует много времени для завершения, то, как предлагается, пусть процесс создает файл pid и ищет этот файл при запуске. Если файл существует, выдайте сообщение и завершите работу. В противном случае запускайте как обычно.
Если вы имеете в виду демона (иногда называемого службой), вместо использования cron вам следует взглянуть на пс-наблюдатель, Я использую его для того же.
С веб-сайта: «... его можно использовать, чтобы убедиться, что демон запущен или не запускается слишком много раз. Его также можно использовать для определения того, когда процесс потребляет слишком много ресурсов, возможно, из-за утечки памяти. . "
Вы просто настраиваете ps-watcher для поиска вашего процесса. ps-watcher проверит список процессов, и если он не найден, ps-watcher запустит его за вас.
В зависимости от того, как вы определяете свой процесс, задание cron может выглядеть так:
* * * * * исполняемый файл pidof || / usr / локальный / bin / исполняемый файл
при условии, что ваш исполняемый файл представляет себя в списке процессов. Более разумным способом было бы иметь pid-файл и использовать start-stop-daemon. Собственно, все зависит от рассматриваемого процесса. Некоторое время назад я также написал небольшой демон обслуживания процессов дудки именно для этого.
И нет, cron не будет блокировать, но, в зависимости от характера вашего процесса, вы все равно можете захотеть сделать его фоновым.
контролировать был разработан для решения этой проблемы.