Альтернатива Daemontools (djbtools) для контроля процессов Unix?
Я использовал Daemontools, чтобы предоставить простой и надежный способ контроля сервисов Unix на моих серверах. Это работает хорошо, но требует другого мышления ( The DJB Way), и некоторые распространенные жалобы:
- Временные метки на основе TAI64N
- Не хранит скрипты в /etc/init.d (или (/usr/local)/etc/rc.d)
- Не всегда работает с такими скриптами, как apachectl. Некоторые сценарии необходимо переписать.
Я помню, что некоторые похожие демоны "supervisor/watchdog" были в работе около двух лет назад, но некоторые все еще были немного грубыми по краям.
Если вы перешли с Daemontools на что-то другое, что вы выбрали и хорошо ли это сработало для вас? RedHat или Ubuntu поставляются с какими-либо утилитами супервизора процессов по умолчанию?
9 ответов
Хм, если вы используете Ubuntu, их новый процесс инициализации, upstart, включает в себя уровень контроля процесса. Он может использоваться для стандартного запуска и остановки служб, как сценарии инициализации SysV, а также может отслеживать запущенные приложения и вызывать их, если они умирают.
Вы также можете реализовать перезапуск процесса для бедного человека через inittab, в зависимости от ваших потребностей.
Если вы в первую очередь ищете что-то, чтобы следить за процессом, чтобы убедиться, что он всегда запущен, а затем перезапустить его, когда это не так, мне очень повезло с рестартом. К сожалению, единственный известный мне источник - это пакет Debian. Однако это очень маленькое и простое приложение, в основном просто один файл.c и.h, с файлом make. Компилировать его из исходного архива Debian в Red Hat тривиально (я даже сделал его RPM на своей предыдущей работе).
Последний вариант, о котором я слышал, но не использовал, это Supervisor. Это выглядит как многообещающий инструмент, но рестарт работал достаточно хорошо для меня в прошлом, для того, что мне было нужно, что я еще не удосужился поиграть с ним.
+1 за рунит. Больше возможностей и гибкость, чем у daemontools, совместимых с существующими аргументами и опциями daemontools. Довольно аккуратно.
Но, как вы упомянули, многие инструменты поставляются со своими собственными двоичными файлами управления, apache2ctl, ejabberdctl, poundctl, collectd и т. Д. И хотя хаки существуют, иногда просто лучше придерживаться поставляемых инструментов, в основном, когда вы не уверены в чистоте возможная реализация. Я обычно иду на компромисс, и большинство служб работают под наблюдением Рунита. А другим разрешено бегать тривиальным способом.
Ну, есть рунит. Я не могу сказать вам, в чем его отличие и сходство с daemontools, но, судя по веб-сайту Berstein-esque, я бы сказал, что есть определенное влияние Бернштейна.
В качестве альтернативы уже упомянутым daemonize а также daemontools, есть команда daemon пакета libslack.
daemon вполне настраивается и заботится обо всех утомительных вещах демона, таких как автоматический перезапуск, ведение журнала или обработка pidfile.
Fedora, похоже, готова перейти на systemd: http://0pointer.de/blog/projects/systemd.html
Есть также инструмент- демон libslack, написанный на C и доступный для различных (Unix) платформ.
Он достаточно настраивается и заботится обо всех утомительных вещах демона, таких как автоматический перезапуск, ведение журнала или обработка pidfile.
Ubuntu поставляется с Upstart - я мало что знаю об этом, но знаю, что у него есть возможности "супервизора". Applet launchd - это еще один вариант (в этой статье Википедии есть хороший раздел "см. Также", в котором также перечислены и другие, в том числе Upstart и RunIt).
У всех них есть свои плюсы и свой особый бренд übersuck - всякий раз, когда кто-то спрашивает меня о программах "супервизор процесса"/"сторожевой пес", я всегда задаю один и тот же вопрос: зачем он вам нужен?
Для этого нет популярных / общедоступных инструментов для достижения консенсуса, потому что каждый, кто идет этим путем, понимает, что это тупик. Если ваши долго выполняющиеся процессы слишком часто терпят неудачу, чтобы простой мониторинг был достаточно хорошим, прекратите их использовать и поместите свой код в нечто, что будет в большей степени зависеть от событий.
редактировать: как указывает Крис ниже, иногда вы полностью загнаны в угол, и в этом случае задание */1 cron, которое ищет файл процесса / pidfile, запускает запуск / перезапуск, если его не хватает, и выводит результаты в электронном письме ответственному лицу. разработчик / менеджер по продукту - ваша запасная позиция.