А я говорю конкретно про Ubuntu. Upstart был там аж с 2006 на подтанцовках, а с 2009 уже во все поля. За пять лет ничего толком не изменилось, в 14.04 Apache так и стартует до сих пор из SysV.
Уже говорил тут, но повторю еще раз: денег Canonical должно было бы хватить не только запилить Upstart, но и потрудиться для него написать скрипты для программ. А этого сделано не было, SysV всех устраивал.
Спасибо за ссылку. Увы, не уверен, поскольку я предпочитаю автоматизироваться через chef и использовать все-таки нативные инструменты.
По сути, как гениально не пиши, но получится еще один бинарь /usr/sbin/service, который должен за меня что-то сделать. Я не вижу в этом особого смысла, поскольку предпочитаю общаться с systemd, например, самостоятельно.
Про установку пакетов еще хитрее. На сегодня не автоматизировать свою работу может только админ, у которого много свободного времени. У меня процентов на 70% прод работает из Chef, поэтому я и так уже говорю «Chef, мне тут пакеты накатить, разбирайся как».
Вы простите, но я не писал статью с обзором про systemd, таких обзоров на Хабре тысячи.
Мне хотелось пояснить, что в королевстве Debian/Ubuntu плохо с системой инициализации. Плохо по целому ряду причин. О которых я в полушутливой форме рассказал.
Для модульной системы необходимо чётко очерченные открытые интерфейсы. Если они меняются каждый релиз, то система, пусть даже разбитая на несколько файлов, останется монолитной.
systemd состоит из разных бинарей. Никто не мешает Вам написать свой. Просто ныть о модульности любят, обычно, те, кто ничего писать и не собирался, а просто повторяет «монолитно это плохо», как мантру.
Соглашусь про Arch, там systemd в полной мере и крайне хорош. Увы, Arch как по мне не достает неких LTS-версий, ну уж больно rolling release.
А про мейнтейнеров дебиана — я здесь могу только удивляться, поскольку по идее денег Canonical должно было бы хватить, чтобы для всего более или менее важного запилить скрипты на systemd.
Видите ли, логика простая. Один бэби-ситтер для всех лучше, чем каждый софт со своим бэби-ситтером, это раз. Далее, не все бэби-ситтеры одинаково хороши, это два. Разработчик должен писать софт, а не бэби-ситтеров, это три.
systemd можно собрать мизерным, если выключить то, что не нужно. Кроме того, монолитность его сильно преувеличена, это набор мелких инструментов, которые взаимодействуют между собой.
Поверьте, уклад жизни админа начал меняться еще с Upstart. Потом стал меняться, когда стало понятно, что Debian тоже перейдет на systemd. Возможно, изменится еще раз, но пока systemd обладает всеми шансами на статус нового SysV. Поэтому автору крайне хочется, чтобы systemd стал стандартом у разработчиков софта.
Поверьте, systemd и наблюдение за службами еще как надо на серверах. Потому что хочется быть уверенным, что если служба вылетит с segmentation fault или еще как, будет кому подхватить упавшее знамя.
Я знаю про cgroups и limits, но в рамках статьи, в масштабах зоопарка старта обычных служб счел это не таким уж важным. В проде больше всего наблюдаю cgroups и limits как раз для JVM, но у меня его в проде нет.
Он, судя по всему, не пытается. Из документации следует, что если эта проверка фейлится, то systemd делает вид, что все хорошо и не переводит unit в режим failed.
Before starting a unit, verify that the specified condition is true. If it is not true, the starting of the unit will be (mostly silently) skipped, however all ordering dependencies of it are still respected. A failing condition will not result in the unit being moved into a failure state.
--daemon — а зачем? Как только оно делает fork и отваливается потом, systemd не может гарантировать, что все хорошо. Type= не указано, поэтому systemd считает, что это simple.
1. Я бы попробовал добавить Type=forking в секцию Service.
2. У rsync очень особое понимание того, как оно запущено. --daemon обозначает не просто fork, а еще пояснение, что rsync запускается не из под inetd. Интереса ради я бы попробовал бы еще вот так:
init — всегда единая точка отказа. Коряво собранный initramfs — единая точка отказа. Корявый модуль ядра — единая точка отказа.
Если проблемы у init, то все остальное уже неважно. И эта логика в systemd хороша.
Уже говорил тут, но повторю еще раз: денег Canonical должно было бы хватить не только запилить Upstart, но и потрудиться для него написать скрипты для программ. А этого сделано не было, SysV всех устраивал.
По сути, как гениально не пиши, но получится еще один бинарь /usr/sbin/service, который должен за меня что-то сделать. Я не вижу в этом особого смысла, поскольку предпочитаю общаться с systemd, например, самостоятельно.
Про установку пакетов еще хитрее. На сегодня не автоматизировать свою работу может только админ, у которого много свободного времени. У меня процентов на 70% прод работает из Chef, поэтому я и так уже говорю «Chef, мне тут пакеты накатить, разбирайся как».
Но за ссылку еще раз спасибо, интересно.
Мне хотелось пояснить, что в королевстве Debian/Ubuntu плохо с системой инициализации. Плохо по целому ряду причин. О которых я в полушутливой форме рассказал.
systemd состоит из разных бинарей. Никто не мешает Вам написать свой. Просто ныть о модульности любят, обычно, те, кто ничего писать и не собирался, а просто повторяет «монолитно это плохо», как мантру.
А про мейнтейнеров дебиана — я здесь могу только удивляться, поскольку по идее денег Canonical должно было бы хватить, чтобы для всего более или менее важного запилить скрипты на systemd.
systemd можно собрать мизерным, если выключить то, что не нужно. Кроме того, монолитность его сильно преувеличена, это набор мелких инструментов, которые взаимодействуют между собой.
Я ни разу не забывал, что init — это простой скрипт, ну и что? Это как-то уменьшает его недостатки?
Ну и про альтернативные точки зрения. Для отладки можно (и нужно) запускать демон самому с нужной командной строкой. В чем проблема?
Разработчикам пофиг, они только SysV поддерживают. Мэйнтейнеры пакетов обычно кладут на необходимость создания unit-файлов, ведь SysV же работает.
Замкнутый круг.
Я не понимаю, что здесь нелогичного?
--daemon — а зачем? Как только оно делает fork и отваливается потом, systemd не может гарантировать, что все хорошо. Type= не указано, поэтому systemd считает, что это simple.
1. Я бы попробовал добавить Type=forking в секцию Service.
2. У rsync очень особое понимание того, как оно запущено. --daemon обозначает не просто fork, а еще пояснение, что rsync запускается не из под inetd. Интереса ради я бы попробовал бы еще вот так:
[Service]
Type=simple
ExecStart=/usr/bin/rsync