Делаю пост сюда, чтобы линковать его людям. Ибо на лоре есть разметка
Ситуация: Живём много лет на sysvinit, появляются всякие openrc и upstart, на которых работают две системы их большого количества. Появляется systemd и сразу большое количество систем переходят на него. Почему? Обьясню на примере debian, тестовой ветки и systemd из этой же ветки.
Почему появилось желание поменять sysvinit на чтото другое?
1) Структура скриптов для sysvinit подразумевает только возможность запуска скриптов с флагами start и stop. Внутреннее устройство скрипта ЦЕЛИКОМ на совести разработчика. Конечно это не повод считать что все скрипты для sysv говно, но всётаки встречаются такие экземпляры, что хочется просто плакать, когда их читаешь. Особенно изза того, что большую часть логики слежением за стотоянем службы пишется на баше. Хотя нынче половина инит скриптов завязанны на start-stop-service. В итоге - каша.
2)Никаких средств для учёта очерёдности запуска сервисов и паралельной их загрузки. Да, есть insserv, только оно ещё больше каши добавляет в скрипты инициализации.
Почему не upstart?
Уже несколько лет в дебиане висит, и ещё не пыталось стать стандартной системой инициализации. В нынешней ситуации, когда говорят о фичах, которые уже есть в других системах инициализации - говорят - «пфф, мы можем тоже такое написать» (тот же cgroup). В итоге функционал апстарта в текущем его состоянии ушёл не дальше sysvinit+insserv+start-stop-daemon. Зато хипстер-аура вокруг него просто знатная.
Почему не openrc?
Оно ещё старше, чем upstart, но разговоры о нём толком начались только при выборе между upstart и systemd. В итоге оно на бумаге конечно лучше чем systemd, но практически это даже проверить не возможно. Некая мифическая сущность, сферическая и в вакууме.
Почему systemd?
1) Он уже работает в тестинге, и не полагется на fallback на sysvinit. Когда я последний раз пробовал upstart без sysvinit скриптов он не работал, и все его преимущества скатывались в ничто. Просто не использовались. В итоге ситуация выглядит так:
systemd - сначала сделали поддержу, потом ещё предложили как стандарт.
openrc и upstart - сначала предложили, а поддержки нету, никакой. Вот если выберут - то поддержка будет. По мне - нарушение причинно-следственной связи.
2) Использование cgroup невероятно упрощает внутреннюю логику юнитов для запуска сервисов. СИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИЛЬНО.
Вот например юнит для bluetooth демона
[Unit]
Description=Bluetooth service
[Service]
Type=dbus
BusName=org.bluez
ExecStart=/usr/sbin/bluetoothd -n
[Install]
WantedBy=bluetooth.target
Alias=dbus-org.bluez.service
а теперь выполним одну весёлую комманду
khades@debian:/etc/init.d$ cat /etc/init.d/bluetooth |wc
201 584 4474
А теперь о мифах про systemd.
JOURNALD БИНАРНЫЕ ЛОГИ ХУЖЕ ЧЕМ В RSYSLOG
syslog - это стандарт отправки и регистрации сообщений о происходящих в системе событиях
rsyslog - программа для организации хранения этих сообщений, полученных по системной шине, реализованной в ядре linux (/dev/log)
journald - легковесный сервис для хранения и чтения логов с хранением их в памяти для ускорения процессов ввода\вывода во время загрузки с ОПЦИОНАЛЬНЫМ хранением бинарей на диске. НЕ ЛОМАЕТ rsyslog.
PID 1: ВСЁ УПАДЁТ ЕСЛИ УПАДЁТ SYSTEMD
1) Почему systemd должен упасть?
2) Ядро тоже падает, давайте все ненавидеть ядро
PID 1: СИСТЕМД МНОГО ВСЕГО В ОДНОМ ПРОЦЕССЕ ДЕРЖИТ И МНОГО НА СЕБЯ БЕРЁТ!!!!
1) Для изоляции запускаемых процессов и придуман CGROUP.
2) khades@debian:~$ ps aux |grep systemd root 284 0.0 0.1 297788 11032 ? Ss фев13 0:01 /lib/systemd/systemd-journald root 295 0.0 0.0 42944 1924 ? Ss фев13 0:00 /lib/systemd/systemd-udevd root 2448 0.0 0.0 36928 1636 ? Ss фев13 0:00 /lib/systemd/systemd-logind
ПОТЦЕРИНГ ЧТОТО ПОМЕНЯЕТ И ВСЁ СЛОМАЕТСЯ
Даа, и это сразу попадёт в стейбл дебиана. инфа 100%.
И последнее, касаемо непортируемости на другие ядра. В нашем случае глупо не использовать передовую технологию (CGROUP) ради совместимости с принципиально другой системой, учитывая то количество ништяков, которое оно нам даёт реализовать. Я вообще в далёком будущем представляю как на помойку выкидывают selinux, потому что домены безопасности реализуют на основе namespaces и cgroup. Ах мечты, мечты.
