Development for Linux
Comments 20
0
Подскажите, пожалуйста, какая разница между этим решением и supervisord?
Или эти приложения используются для разных целей?
+6

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


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

0
ну видимо теперь это из коробки
UPD: не обновил комментарии.
+1
supervisord — посторонний софт, которого даже в штатных репозиториях нет. systemd уже есть и (после выхода ubuntu 16.04) можно сказать, что есть всюду.
0

Про различия ответили, но хочу немного добавить.


Пользуюсь supervisord уже более 5 лет, и соглашусь со многими что — он с костылями, в этом нет ничего плохого )
Хотя бы то что он не может "убить" дочерние процессы запущенные не им
Сам не однократно испытывал проблемы при stop all и start all.


Так что если есть возможность, то лучше избегать supervisord.

0
Увы, слушать на одном порту внесколькером нельзя. Даже с опцией SO_REUSEPORT. Но это не закрывает саму возможность использовать отдельные процессы в качестве worker'ов. Можно сделать предельно простой менеджер, который будет принимать все соединения сам и сразу же передавать уже открытые сокеты worker'ам через shared memory.
0
Еще удобно использовать monit для этих целей. Поднимет, если упадет и отправит уведомление админам.
+2

Системдешные атрибуты сервисов OnFailure, Restart и RestartSec сделают то же самое.

0
Да, но systemd все-таки (пока что) не умеет в e-mail, очень вкусные сервис-чеки и mmonit.
0
а еще можно использовать runit. к тому же, к нему есть отличный веб-интерфейс runit-man. пользуюсь им с 10-го года, он очень простой и этим очень подкупает. с тех пор ни разу меня еще не подвел.
к сожалению, без внешних костылей скриптов повторить то, что описано в статье — нельзя.
0

Когда использовал runit в прошлый раз — он не умел в зависимости от слова совсем. Что-нибудь изменилось на этом фронте?


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

0
автор предлагает такой вариант. не очень изящно :)

Upstart, конечно, в этом плане тоже не сахар, если конкретный сервис зависит от более чем одного стороннего

там вроде есть броадкаст-сигналы(emits), давно это было.
0
автор предлагает такой вариант. не очень изящно :)


Этот костыль я видел, но он не связывает состояния сервисов: при запуске 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.
0
мы используем runit для сервисов, котрые всегда работают(около 16 тысяч машин) и он себя зарекомендовал очень хорошо. ну и вообще, удобно, когда мухи от котлет, в смысле системные сервисы и конторские отдельно лежат, можно, например, сделать sv status /etc/service/*, чтобы получить полное предствление о происходящем на машине.
0
А можно подробности про написание сервисов. В частности, интересно как в сервисе прописать последовательность действий? (а не одну команду)
+2
Если нужно запустить команды до или после старта, то есть `ExecStartPre=` `ExecStartPost=` и тому подобное для остановки и других действий. Совсем сложную логику лучше вынести наружу в обычный shell скрипт. Systemd — это дирижер, он не должен играть за музыкантов.
+2

Ещё есть зависимости вида After и Before, которые в сочетании с Requires позволяют запускать сервисы после и до заданного.

0
Последнее, что я видел — обычный хак с bash -c «foo --one|bar --two && three».
Only those users with full accounts are able to leave comments. , please.