Служба перезапускает (безопасно, затем, если это не удается, принудительно) несколько разных процессов по расписанию


0

В настоящее время я работаю над личным проектом, который в основном контролирует несколько вещей круглосуточно. Один - это процесс, который использует PhantomJS, а другой сканирует некоторые другие API и отправляет электронные письма, если возникает определенная ситуация.

Когда все запущено и работает, все работает именно так, как я хочу, но, к сожалению, в настоящее время каждые 2-3 дня что-то происходит обычно в глубокой ночи, и сканер API просто зависает. Он написан на Python и запускается каждые три секунды, и когда я проверяю журнал на следующий день, никаких сбоев нет, ничто не выглядит необычно, но по какой-то причине он перестает работать.

Когда у меня будет время, я в конце концов найду время, чтобы исправить это, но поскольку это происходит только один раз через 3 или 4 дня подряд, воспроизвести его было очень сложно.

Для материала PhantomJS ... время от времени это просто взрывается. Опять же, там будет происходить очистка, исправление этих проблем и, возможно, полная их замена.

Но, в то же время, что бы я люблю сделать, это перезапустить их каждые 24 часа в сутки. Это определенно не идеально, но то, что я сейчас делаю, решит 99% моих проблем.

В идеальном мире у меня был бы список процессов в сочетании со списком PID. Каждые 24 часа, в то время, когда я запретил, я хочу, чтобы этот контроллер проходил через каждый из PID, отправлял обычный сигнал уничтожения (один из них обращается к БД, поэтому я бы хотел, чтобы он безопасно закрывался, если возможно), затем подождите в течение запрещенного периода времени (скажем, 30 секунд), затем отправьте sudo kill -9сигнал в PID для аварийных аварийных ситуаций, а затем снова запустите команду запуска.

Я изучил, может быть, использовать Supervisorдля этого, но не казалось (на первый взгляд), чтобы сделать то, что я ищу.

Я полностью согласен с тем, что могу использовать для этого 2-3 разные программы (например, cron + supervisord + python) вместо того, чтобы искать одну, если не существует единственного идеального решения.

Ответы:


1

Мое предпочтительное решение - это скрипт Python, управляемый cron, который в первую очередь заботится о запуске отслеживаемых процессов, когда они не запущены. Он может сам получать и хранить PID дочерних процессов (и, возможно, другие метаданные, если необходимо, например, отметку времени последней итерации OK) для последующего использования или просто отслеживать такие файлы, которые сами дочерние процессы создают.

На первой итерации я бы использовал преимущества относительно предсказуемых шаблонов / сроков сбоев и изменил бы соответствующие дочерние процессы, чтобы просто аккуратно завершать работу после определенного числа итераций или общего времени выполнения. Процесс мониторинга просто перезапустит их.

В дальнейшем сценарий мониторинга может быть улучшен для более детального анализа работоспособности отслеживаемых процессов и их уничтожения при необходимости. Например, проверяя их последнюю отметку времени итерации, о которой я упоминал выше. Это позаботится о меньшем количестве прогностических паттернов.

Для фактического уничтожения более сложных структур процессов вы можете проверить мой ответ на этот вопрос: https://stackoverflow.com/questions/30780487/python-script-to-monitor-process-and-sub-processes .


«заданное количество итераций общего времени выполнения» - это то, что я просто никогда не думал проверять вообще. Возможно, это будет реализовано сразу же, прежде чем поставить на место полную проверку. Остальная часть вашего ответа определенно там, где была моя голова, и я отмечу это правильно, если ничего лучше не покажет. Спасибо Дэн.
моряки

Тьфу - у меня была опечатка, должно быть "определенное количество итераций orобщего времени выполнения" ... В зависимости от того, что удобнее.
Дан Корнилеску

Ты в порядке! Я читаю это как «количество итераций во currentвремя выполнения», которое, в любом случае, может подразумеваться, но все же имеет смысл. Я уже записываю текущее и общее время, так что это определенно полезно, чтобы проверить, есть ли корреляция.
моряки
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.