Комментарии 20
Или эти приложения используются для разных целей?
Супервизорд написан на питоне и надо ставить отдельно.
Системд доступен на большинстве современных дистрибутивов из коробки и написан на Си.
Системд, кроме всего прочего, управляет всей системой, а не только одним сервисом, то есть более универсален,
плюс предоставляет гораздо более широкие возможности по тонкой настройке и изоляции доступных ресурсов.
Вообще супервизорд был написан в стародавние времена убогого SysV, который только запускает-останавливает сервисы,
не давая таких широких возможностей для настройки среды процессов, их перезапуска и т.п.
Так что в наше время, когда есть апстарт и системд, которые уже умеют всё это, он выглядит просто древним костылём.
UPD: не обновил комментарии.
Про различия ответили, но хочу немного добавить.
Пользуюсь supervisord уже более 5 лет, и соглашусь со многими что — он с костылями, в этом нет ничего плохого )
Хотя бы то что он не может "убить" дочерние процессы запущенные не им
Сам не однократно испытывал проблемы при stop all и start all.
Так что если есть возможность, то лучше избегать supervisord.
Системдешные атрибуты сервисов OnFailure, Restart и RestartSec сделают то же самое.
Вот с такими костылями может и email.
Когда использовал runit в прошлый раз — он не умел в зависимости от слова совсем. Что-нибудь изменилось на этом фронте?
Upstart, конечно, в этом плане тоже не сахар, если конкретный сервис зависит от более чем одного стороннего, но существенно лучше чем отсутствие поддержки совсем.
Upstart, конечно, в этом плане тоже не сахар, если конкретный сервис зависит от более чем одного стороннего
там вроде есть броадкаст-сигналы(emits), давно это было.
автор предлагает такой вариант. не очень изящно :)
Этот костыль я видел, но он не связывает состояния сервисов: при запуске cron'а в этом примере будет выполнена попытка запустить socklog-unix. При останове cron'а не произойдёт ничего, и, хуже того, при останове socklog-unix не будет остановлен cron, если он не упадёт сам.
там вроде есть броадкаст-сигналы(emits), давно это было.
И плюс сигналы started/stopping, но делать зависимость от двух сервисов там геморрой.
Допустим, что s1 зависит от s2 и s3 и требуется работа обоих для работы s1. Тогда можно написать
start on started s2 and started s3, stop on stopping s2 or stopping s3. Допустим, всё запущенно и необходимо перезапустить s2. При restart s2 произойдёт останов s1 (по событию stopping s2), а запуск s1 не произойдёт, т. к. было starting s2, но не starting s3.В случае systemd будет достаточно двух зависимостей типа requires.
Запуск worker'ов сервиса с помощью systemd