Назад | Перейти на главную страницу

Сценарий оболочки для выполнения чего-либо, когда один из демонов умирает?

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

Как я могу выполнить автоматическое выполнение задачи (например, сценария оболочки) для проверки обоих демонов, когда один из них не работает?

Что за скрипт, который всегда может проверить жизнь демона и, возможно, сможет выполнить некоторые другие задания, если один из демонов случайно остановится?

monit в этом случае замечательно - он работает на локальном хосте, поэтому вам не нужно сетевое соединение для перезапуска вашего демона (в случае его сбоя, или демон отвечает за сеть). Он также занимает мало места в системе, и вы можете использовать его для мониторинга других ваших демонов / дискового пространства / и т. Д. также.

Создайте сценарий запуска / остановки (аналогичный тем, что в /etc/init.d/ и создайте для него символические ссылки на уровнях запуска, которые ваша система использует для нормальной работы, гарантируя, что ваш демон будет запускаться при перезагрузке и останавливаться при завершении работы должным образом. Если у вашего демона нет pidfile, создайте его, используя start-stop-daemon сценарий.

После этого устанавливаем monit и создайте конфигурацию для вашего демона, примерно так:

check process daemond with pidfile /var/run/daemond.pid
    start program "/etc/init.d/daemond start"
    stop program "/etc/init.d/daemond stop"
    if failed port 1234 type TCP for 5 times within 10 cycles then restart
    if 3 restarts within 5 cycles then alert

Эта конфигурация гарантирует, что если демон перестанет отвечать на tcp-порту 1234 или перестанет работать, он будет перезапущен с помощью сценария инициализации. monit также отправит вам оповещение по электронной почте или сделает другие действия, в зависимости от того, как вы его настроите. Просто проверьте monit(1) справочная страница.

Во многом зависит от демона.

Если у демона есть API, и вы можете связываться с ним через сокет TCP / IP или сокет UNIX, тогда вы можете это сделать.

Если он, например, прослушивает порт TCP / IP, вы можете написать сценарий, который подключается к нему, ожидает определенного ответа - а также подсчитывает, сколько времени потребовалось, чтобы получить этот ответ - вы можете передать это в инструменты мониторинга, такие как nagios, munin или другой - какой бы скрипт вы в конечном итоге ни написали для выполнения единственной проверки, вы можете легко интегрировать его, например, в плагин nagios - что, вероятно, вы захотите сделать - как только вы напишете свой проверочный скрипт.

Если он не предоставляет вам ничего полезного, не прослушивает порт, все, что вы действительно можете сделать, это проверить дерево процессов с помощью lsof, netstat или чего-то в этом роде и просто убедиться, что оно существует, но вы действительно не можете сделать это чек.

Вам нужно быть более конкретным, прежде чем кто-либо из присутствующих сможет предложить вам что-то полезное.

Взгляните на PID запущенного демона, затем посмотрите под /proc/<PID>/fd чтобы получить представление о том, с какими каналами / сокетами / файлами взаимодействует демон - это может помочь вам начать работу.

Я бы посоветовал использовать вашу (надеюсь) существующую инфраструктуру мониторинга.

Я использую Nagios и опрашиваю свои Linux-машины с помощью SNMP. Linux MIB позволяет мне получать имена всех запущенных процессов, а также PID и аргументы. Я использую это для мониторинга различных демонов (например, crond), которые не открывают порты.

Что ж, у меня есть любимая проверка на что-то невероятно простое, когда оно умирает. Просто запустите его:

/ путь / к / демону || mail user@domain.com "/ путь / к / демон умер; сделать X" или:

пока [[-z ""]]; сделать / путь / к / демону || mail user@domain.com "/ путь / к / демон умер; перезапуск"; сделано

Или что-то вроде того. Если демон завершит работу при возникновении проблемы, это дает вам очень простой и надежный мониторинг.

Возможно, вы могли бы попробовать запустить задачи с помощью демона инициализации (при условии, что это Unix, что, похоже, сделали другие ответы). Ознакомьтесь со страницей руководства для inittab, где подробно объясняется, как это сделать. Вы можете настроить запуск процесса во время загрузки или на определенном уровне (ах) выполнения.

Если вы используете опцию respawn, тогда ваш процесс будет просто перезапущен автоматически в случае сбоя, то есть демон инициализации является встроенным монитором процесса, а также стартером процесса. Тем не менее, демон init также имеет некоторый «интеллект», так что, если ваш демон перезапускается слишком часто за слишком короткий промежуток времени, то в конечном итоге init перестанет пытаться запустить его снова на несколько минут. Это затрудняет, например, случайное использование всего ЦП на компьютере мошенническим процессом.

Обычно init будет настроен для записи в журнал записей в / var / log где-нибудь, так что вы получите ведение журнала бесплатно.

Не уверен, почему никто не перечислил очевидное простое решение:

#!/bin/bash
ps ax | grep "[p]rogie" >/dev/null 2>&1
if [ $? != 0 ] ; then
    # do something
fi

Я бы рекомендовал контролировать, или Бог для такого рода задач с помощью инструмента мониторинга сети, такого как nagios, или настраиваемого скрипта, как рекомендует один из других плакатов.

Другой плакат включал фрагмент конфигурации для Monit; Бог похож по концепции, но написан рубиновым шрифтом. Оба этих инструмента написаны для обработки такой ситуации и обеспечивают гораздо большую гибкость, чем пользовательский сценарий (что, если процесс существует, но не отвечает? Что, если ваш grep соответствует другому процессу, которого вы не ожидали ?) и обеспечить поддержку порога и гистерезиса "из коробки".

Я мог бы использовать Nagios в качестве отдельного пути для предупреждений и уведомлений, но я бы не стал использовать его в качестве единственного способа мониторинга и перезапуска процесса по той же причине, по которой я не использовал бы рукописные скрипты - он не обеспечивает достаточной гибкости для большинства ситуаций мониторинга, и хотя вы можете инициировать события (например, перезапуск службы), он не обладает гибкостью, чем такие инструменты, как monit.