Неожиданное завершение процесса, запущенного через nohup?

Question

[Snowindy]

Ситуация:

Есть веб-сервер, процесс которого может самопроизвольно завершиться (ошибка, OutOfMemory, что угодно).


Для того, чтобы сервер поднимался автоматически после падения, написал специальный скрипт:

run-loop.sh

while :
do
echo "inifinite loop iteration..."
./start-server.sh
echo "inifinite loop iteration ended, sleeping for some time"
sleep 60
done

Запускаю все дело так из сессии ssh специального пользователя (не root):
nohup ./run-loop.sh > logs/server-out.log &


Скрипт-враппер работает нормально в тестах, проверял: если убить процесс сервера через kill -9, он поднимается через минуту.


Тем не менее, периодически (время плавает, 1-7 суток нормальной работы обычно) обнаруживаю, что нет ни одного из процессов пользователя: ни процесса враппера с циклом, ни процесса сервера.

В логах сервера ничего нет полезного, как будто его штатно выключили, в server-out.log тоже ничего.


Как понять, кто убил процессы пользователя? Может ли сервер завершаться с каким-то особым кодом ошибки, вырубающим все скрипты по цепочке? Где искать логи и концы?


Uptime говорит, что железный сервер не перезагружали.

Операционная система: FreeBSD 9.x.

UPDATE:

Убрал враппер, реализовал проверку сервиса через cron, работает.

Answer 1

[Ярослав]

Немного смущает строчка про OutOfMemory. Это просто для примера написано, или на самом деле такая ошибка иногда случается? Просто на линуксе, когда случается, это плохо, и чтобы хоть как-то система жила, ядро прибивает «кого попало», случайный процесс. Так что, если во фре подобная же схема — может быть по этой же причине сам шелл-скрипт убивается? В логах, наверное, OOM должен отражаться.

Но как вариант, если цель не разобраться, а просто решить проблему, лишь бы работало — можно попробовать без враппера. Просто по крону запускать простенький «чек-респаун» скрипт, который будет проверять, и если сервер лежит (по лок-файлу, открытому порту или даже тупо по ps'у) — запускать его снова. В этом случае уже скрипт не умрет по непонятной причине. Разве что умрет cron от ООМа, но если cron умрет — уже точно будете знать, что проблема не в кривом коде крона.

Comments

[Вячеслав Слинько]

Скорее всего имелась всего ошибка OutOfMemory в Java.
Там свой лимит памяти и эта ошибка довольно популярна.

[Snowindy]

Да, имелась ввиду ошибка OutOfMemory в Java.

Это возможно, что в OS не хватило памяти в один прекрасный момент, и были убиты процессы пользователя… Где может отражать этот факт — что было убито, в какой момент и т.п.?

Воспользуюсь вашим советом, переведу велосипед на нормальное решение…

[vsespb]

в linux OOM killer пишет в syslog

Answer 2

[jj_killer]

Есть такой вариант: github.com/visionmedia/mon

Comments

[Вячеслав Слинько]

+1 к специализированным тулзам:
mon
forever
bluepill
god
monit

[Snowindy]

А можно ссылки на эти тулзы?
К примеру, «freebsd god» дает все что угодно, но не утилиту и туториалы…

[jj_killer]

god – это достаточно древняя тулза написанная на руби. Современный аналог – bluepill. Но он тоже тянет как зависимость руби. Как по мне, лучше все же использовать mon или monit. Первый максимально прост, как раз замена шелл-скриптам, второй это как бы стандарт для всеобщего мониторинга (cpu, свободное место и дескрипторы). Если есть время, то лучше все же настроить monit.

[Snowindy]

С mon у меня уже все удалось: github.com/visionmedia/mon/issues/29 :(

Читаю monit…

Answer 3

[Сергей Петриков]

Можно использовать monit
Попробуйте вручную послать SIGTERM на run-loop.sh, какова реакция? В Вашем варианте есть вертушка, перезапускающая процесс, но нет контроля работы самой вертушки, ну и не плодите велосипеды, все давно придумано (см. выше про monit)