В процессе установки ПО для FreeBSD "правильные" службы автоматически прописывают скрипт запуска
в /usr/local/etc/rc.d и управление его поведением определяется в /etc/rc.confОднако случается так что успешно запустившись при включении сервера, служба по ряду причин падает позже
в процессе работы (такое случается например c dovecot или squid). В результате чего как минимум
требуется перезапуск с последующим анализом причин поведения. Про анализ причин поведения отдельная песня,
а вот перезапускать в таких редких случаях ручками может получиться с изрядными задержками,
пока не выяснится, что что-то перестало работать.На этот счет я практикую запуск через cron команды которая проверяет все сконфигурированные к запуску
скрипты /usr/local/etc/rc.d на предмет поддержки команды status и если эта команда возвращает
отрицательный результат (т.е. сервис не активен) то заново запускает его.Итого в файле /var/cron/tabs/root значится строка
*/5 * * * * /usr/bin/find /usr/local/etc/rc.d/ -type file | xargs -I$ sh -c "($ 2>&1 | grep -q -v status) \
&& exit ; ($ status > /dev/null) && exit ; $ start"В итоге, если служба остановилась, она будет перезапущена в течении 5 минут, и на root придет сообщение
с логом запуска (если конечно почтовая подсистема настроена)
URL:
Обсуждается: http://www.opennet.me/tips/info/2086.shtml
Хорошая заметка, у меня пару раз postfix падал
По-моему такой вариант не всегда подходит.. например squid бывает (редко) вылетает а стартовать потом отказывается потому что кэш надо починить squid -z, у меня просто в кроне каждую минуту скрипт вызывается который проверяет нужные службы и в случае если служба не работает, то перезапускает её с необходимыми доп. действиями. Так же например у clamav иногда какие-то косяки с базами случаются что их надо удалять и заново закачивать..
>По-моему такой вариант не всегда подходит.. например squid бывает (редко) вылетает а
>стартовать потом отказывается потому что кэш надо починить squid -z, у
>странно у вас, люди спецом под кеш разделы выделают, накапливают его и лелеют, а вы всё время его сбрасываете, какой смысл тогда от прокси? тока ACL чтоли?
это что же вы такое с ним делаете, что он падает? у меня он не падал с нагрузкой в 60М сообщений в сутки. На FreeBSD 6.3.
звучит как, он у меня не падал без нагрузки
monit спасет отцов русской демократии )
http://www.lissyara.su/?id=1268
daemontools еще есть
а monit использовать не разумнее?
Не имею ничего против monit или daemontools. Но хочу особо подчеркнуть, что по сути одна строчка в единственном файле призывает на службу достаточно неплохие штатные возможности для уменьшения рисков от простоя служб.P.S. Всегда можно сочинииь ситуацию в которой не мпоможет ни мой скрипт, ни monit ни кто другой.
Ваш скрипт в отличие от monit не учитывет вариант когда сервис по каким то причинам не стартует в принципе и будет флудить бессмысленными собщениями на почту.
http://www.freshports.org/sysutils/monitord/"This port allows one to monitor other standalone services and
automatically restart them if they are accidentally and unwittingly
terminated, or crash either because of instability or a DoS attack.
It simplifies a task capable of being performed by cron(8) by not
requiring custom scripts to be written for each service being
monitored. The configuration file is simple and easily setup."
Для FreeBSD'шников - не няшно - оно просит procfs ...
А что нельзя примаунтить ее?
ммм... вроде как в юниксах всегда демоны были, не службы? службы это из другой оперы
Алексей, а мне Ваш скрипт нравится. Я "малую механизацию" вообще уважаю :)(Спокойно! Там где нужна "тяжелая", она и стоит.)
Для тех кому нужно "кэш в сквиде почистить перед стартом" рекомендую творчески подойти к самой последней части скрипта "$ start" ...
Тем кто боится что оно "закидет" бессмысленными email-ами ... Если уж вы чего то ради поставили бох на мониториг - в таком письме очень много смысла! И наводит на мысли о премии которая была так близка и еще есть пол часа чтобы ssh'нуться и еЯ спасти ... :)
Ну и _12_ писем в час для реального админа - это скорее ТИШИНА :)
>Алексей, а мне Ваш скрипт нравится. Я "малую механизацию" вообще уважаю :)Хорошо показывает возможности "голой" системы, и они таки есть :)
BTW - в Solaris 10 очень неплохо SMF сделан, если ему отрезать его XML-ность, то пожалуй это будет то чего я хочу в следующей фряхе! :)
> Ну и _12_ писем в час для реального админа - это скорее ТИШИНА :)Как по мне - тупо флудить по поводу облома старта процесса 12 раз в час, но при этом зато класть болт на взвисы, потребление CPU и памяти - о каких, нафиг, премиях идет спич при таком подходе к мониторингу?Благородные доны никогда не встречали ситуации когда процесс как живой но по факту давно уже не отвечает или пошел вразнос загрузив проц или выжирая память?Нет, для мелкого скрипта это конечно забавно, но не более того.ИМХО.
Для альтернативно одарённых было написано - что де там где "малой" механизацией не обойдешься - стоит и трудится "большая". Специально для усера294 - могу перевести на Русский упрощённый. Дважды. Да только не поможет :)
Интереснее было бы сделать иначе:
* Собрать информацию о PID-файлах (они характеризуют запущенность демона).
* Повесить wait() на все демоны, которые оставили PID-файлы.
* При окончании одного из демонов в зависимости от кода его завершения принимать решение о перезапуске.А ещё круче - опрашивать демонов на предмет отклика, и если не откликается - то убить и запустить заново. Опрос демона можно делать отдельной программой, специфичной для каждого протокола; а перезапускать как описано в первом абзаце.
кажется, Вам nagios нужен :)
>А ещё круче - опрашивать демонов на предмет отклика, и если не
>откликается - то убить и запустить заново.А вы пробовали по ссылкам народа из коментов походить?А то они дело говорят.Тот же monit и подобные насоветованные в коментах как раз примерно такое и делают... будучи небольшими такими утилитками с кучкой возможностей.
До кучи насчет скриптов есть вот какая мысль: если в системе уже задница, совсем не факт что новый процесс (как то периодический чекер по крону) вообще осилит запуститься.Например, прикиньте - память кончается?А вот возьмет и не хватит ее на старт нового процесса.И чего?В этом плане у мелкого демона-монитора имхо 5 очков форы вперед (он может память себе заранее выделить и будет продолжать работать даже в ситуации "наступила жопа").
Спасибо большое за идею. Вижу не только у меня на новых фрях с новыми сквидами такая проблема возникла... В 6-рках 2-х годичной давности такой проблемы нету... Хотя хз, если обновить то может и будет :(.
она будет перезапущена в течениЕ 5 минутВ течениИ реки, но в течениЕ времени.
Наверное кто-нибудь использует в подобных случаях отправку смс-ок от сервера, как это вообще делается?
Мой оператор мегафон не хочет рассказывать, звонил им в саппорт.
sms via email. Подключается услуга, и достаточно просто отправить письмо на number@sms.ugsm.пумпурум
Либо смастерить smsgate из старенького мобильника. На эту тему была статейка кажется на лисяре. Нашел не поленился http://www.lissyara.su/?id=1787
можно посмотреть алгоритмы в Coyote SMS. По крайней алгоритм работы билайновской проги отправки sms - именно из Койота вычитал.http://forum.altlinux.org/index.php/topic,299.0.html
Syntax error: word unexpected
Собственно скрип не отрабатывает и бросает ошибку