Избегайте PID-файлов, крон или чего-либо еще, что пытается оценить процессы, которые не являются их дочерними элементами.
Существует очень веская причина, почему в UNIX вы можете ТОЛЬКО ждать своих детей. Любой метод (ps parsing, pgrep, хранение PID, ...), который пытается обойти проблему, имеет недостатки и имеет зияющие дыры в нем. Просто скажи нет .
Вместо этого вам нужен процесс, который контролирует ваш процесс, чтобы быть его родителем. Что это значит? Это означает, что только процесс, который запускает , ваш процесс может надежно ожидать его завершения. В bash это абсолютно тривиально.
until myserver; do
echo "Server 'myserver' crashed with exit code $?. Respawning.." >&2
sleep 1
done
Приведенный выше фрагмент кода bash запускается myserver
в цикле until
. Первая строка начинается с myserver
и ожидает окончания. Когда он заканчивается, until
проверяет его статус выхода. Если статус выхода - 0
, это означает, что он завершился изящно (что означает, что вы попросили его как-то отключиться, и он сделал это успешно). В этом случае мы не хотим перезапускать его (мы просто попросили его закрыть!). Если состояние выхода - , а не 0
, until
запустит тело цикла, которое выдает сообщение об ошибке на STDERR и перезапускает цикл (обратно к строке 1) через 1 секунду .
Почему мы ждем секунду? Потому что, если что-то не так с последовательностью запуска myserver
и она сразу падает, у вас будет очень интенсивный цикл постоянного перезапуска и сбоя в ваших руках. sleep 1
снимает с этого напряжение.
Теперь все, что вам нужно сделать, это запустить этот bash-скрипт (возможно, асинхронно), и он будет отслеживать myserver
и перезапускать его при необходимости. Если вы хотите запустить монитор при загрузке (после перезагрузки сервера), вы можете запланировать его в cron (1) вашего пользователя с правилом @reboot
. Откройте свои правила cron с помощью crontab
:
crontab -e
Затем добавьте правило для запуска сценария монитора:
@reboot /usr/local/bin/myservermonitor
* * В качестве альтернативы одна тысяча тридцать восемь; посмотрите на inittab (5) и / etc / inittab. Вы можете добавить туда строку, чтобы
myserver
начинался с определенного уровня инициации и автоматически появлялся.
Редактировать.
Позвольте мне добавить информацию о том, почему не для использования файлов PID. Пока они очень популярны; они также очень несовершенны, и нет никаких причин, по которым вы просто не сделали бы это правильно.
Учтите это:
Переработка ПИД-регулятора (уничтожение неправильного процесса):
/etc/init.d/foo start
: начало foo
, запись PID foo
в /var/run/foo.pid
- Некоторое время спустя:
foo
как-то умирает.
- Некоторое время спустя: любой случайный процесс, который запускается (назовите его
bar
), принимает случайный PID, представьте, что он берет старый PID foo
.
- Вы замечаете, что
foo
ушел: /etc/init.d/foo/restart
читает /var/run/foo.pid
, проверяет, живо ли оно, находит bar
, думает, что это foo
, убивает его, запускает новый foo
.
Файлы PID устарели. Вам нужна слишком сложная (или я должен сказать, нетривиальная) логика, чтобы проверить, не устарел ли файл PID, и любая такая логика снова уязвима для 1.
.
Что если у вас даже нет прав на запись или вы находитесь в среде только для чтения?
Это бессмысленное чрезмерное усложнение; Посмотрите, насколько простой мой пример выше. Нет необходимости усложнять это.
См. Также: По-прежнему ли некорректны PID-файлы при правильной работе?
Кстати; разбирается даже хуже, чем PID-файлы ps
! Никогда не делай этого.
ps
очень непереносимо. В то время как вы найдете его почти в каждой системе UNIX; его аргументы сильно различаются, если вы хотите нестандартный вывод. И стандартный вывод предназначен ТОЛЬКО для потребления человеком, а не для синтаксического анализа!
- Синтаксический анализ
ps
приводит к МНОГИМ ложных срабатываний. Возьмите пример ps aux | grep PID
, и теперь представьте, что кто-то начинает процесс с номером где-то в качестве аргумента, который совпадает с PID, с которым вы смотрели своего демона! Представьте двух человек, начинающих сеанс Х, и вы хотите, чтобы Х убил ваш. Это просто все виды плохих.
Если вы не хотите сами управлять процессом; Есть несколько совершенно хороших систем, которые будут выполнять функции мониторинга ваших процессов. Посмотрите, например, runit .