LINUX.ORG.RU
ФорумTalks

К спорам по systemd и debian

 ,


8

1

Делаю пост сюда, чтобы линковать его людям. Ибо на лоре есть разметка

Ситуация: Живём много лет на 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
И всё, так как bluetooth не требует какойто хитрой логики для остановки сервиса, он просто убивается. Пид ловится через cgroup

а теперь выполним одну весёлую комманду

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. Ах мечты, мечты.

★★

дело в том, что systemdхейтеры это прекрасно знают. это не мешает им присать бред.

x0r ★★★★★ ()

Никто не в курсе, когда планируется выкатить инсталлятор, сразу сетапящий дебиан с systemd?

provaton ★★★★★ ()

Но это же ЧИТАТЬ МАНЫ ОПЯТЬ МЫ РАЗУЧИЛИСЬ ЧИТАТЬ ДАЙТЕ НАМ ЖИТЬ С ИНИТСКРИПТАМИ ЗАЧЕМ МЕНЯТЬ.

x3al ★★★★★ ()
Ответ на: комментарий от provaton

В следующем стейбле. Как он там? Джесси, вроде.

Stahl ★★☆ ()
Ответ на: комментарий от Khades

Я знаю, что системд есть в тестинговом репозитории. Вопрос в том, ставит ли текущий инсталлер тестинга системд, или ставит sysvinit, а системд потом руками прикручивается после установки?

provaton ★★★★★ ()

1) Структура скриптов для sysvinit подразумевает только возможность запуска скриптов с флагами start и stop...

ТС путает rc(.d) и sysvinit. А может и не путает, но описывает так. Мда... Проповедник Поттеринга налицо.

reprimand ★★★★★ ()

паралельной загрузки

1) не нужно
2) было реализовано задолго до

Некая мифическая сущность, сферическая и в вакууме.

не раскурил

упрощает внутреннюю логику юнитов

systemd вообще убивает какую-либо логику в скриптах, из-за чего и не нужен

Ford_Focus ★★★★★ ()
Ответ на: комментарий от Ford_Focus

не нужно

Старт какойнить самбы до старта самой сети это же так весело

systemd вообще убивает какую-либо логику в скриптах, из-за чего и не нужен

лол што? Системд не даёт писать логику там, где она ненужна, изза этого системд ненужен?

Khades ★★ ()

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

qnikst ★★★★★ ()
Ответ на: комментарий от Khades

если тебя интересует именно rc.d

debian

хорошо вбросил, молодец. Особенно порадовала попытка запуска вместо cat. В палату мер и весов!

reprimand ★★★★★ ()
Ответ на: комментарий от Khades

Старт какойнить самбы до старта самой сети это же так весело

нумерация скриптов? не, не встречал.

она ненужна

параметры запуска? не, не нужно. посмотреть что уже запущено и поменять логику / выполнить действия? не, не нужно

Ford_Focus ★★★★★ ()
Ответ на: комментарий от Ford_Focus

параметры запуска? не, не нужно. посмотреть что уже запущено и поменять логику / выполнить действия? не, не нужно

Пример юнита для nginx, где есть всё, о чём вы говорите.

[Unit]
Description=A high performance web server and a reverse proxy server
After=network.target

[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;'
ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'
ExecReload=/usr/sbin/nginx -g 'daemon on; master_process on;' -s reload
ExecStop=/usr/sbin/nginx -s quit

[Install]
WantedBy=multi-user.target[\code]
Khades ★★ ()
Ответ на: комментарий от Khades

ога, вынести логику запуска/стопа в бинарь - это молодца. это пять с плюсом, настоящий Поттеринг-way

Ford_Focus ★★★★★ ()
Ответ на: комментарий от Khades

в init скрипте есть команда update, позвляющая обновлить бинарник nginx без закрытия соединений, покажите пожалуйска, как это выпонляется здесь. Можете ли вы показать, как при запуске сервиса будут обработаны случаи ошибок в конфиге (инит скрипт упадет при проверке со внятным логом и незапуском зависящих сервисов). Так же можно запустить конфигтест отдельно. Без этой логики инит имеет столько же строк:

description="Robust, small and high performance http and reverse proxy server"

nginx_config=${nginx_config:-/etc/nginx/nginx.conf}

command="/usr/sbin/nginx"
command_args="-c ${nginx_config}"
pidfile=${pidfile:-/run/nginx.pid}
user=${user:-nginx}
group=${group:-nginx}

depend() {
	need net
	use dns logger netmount
}

stop_post() {
	rm -f ${pidfile}
}

reload() {
	configtest || return 1
	ebegin "Refreshing nginx' configuration"
	kill -HUP `cat ${pidfile}` &>/dev/null
	eend $? "Failed to reload nginx"
}
qnikst ★★★★★ ()
Ответ на: комментарий от Khades

подмена субъекта - это к специалисту. Это Я недоволен? Смехотворно!

reprimand ★★★★★ ()
Ответ на: комментарий от Khades

1). статус openrc - полный ноль

2). зачем нужны cgroup, и приплетание их к PID 1

3). высказывание про selinux..

Ну а остальное.. я даже не знаю :)

qnikst ★★★★★ ()
Ответ на: комментарий от Khades

и про параметры запуска ты меня очевидно не понял - в ините они задаются с самого начала, прямо под описанием. и использоваться могут много раз по ходу скрипта.

Ford_Focus ★★★★★ ()
Ответ на: комментарий от qnikst

системд скажет - Job for nginx.service failed. See 'systemctl status nginx.service' and 'journalctl -xn' for details.

В journalctl

-- Unit nginx.service has begun starting up.
фев 16 05:34:24 debian nginx[24213]: nginx: [emerg] unknown directive «12user» in /etc/nginx/nginx.conf:1
фев 16 05:34:24 debian nginx[24213]: nginx: configuration file /etc/nginx/nginx.conf test failed
фев 16 05:34:24 debian systemd[1]: nginx.service: control process exited, code=exited status=1
фев 16 05:34:24 debian systemd[1]: Failed to start A high performance web server and a reverse proxy server.
-- Subject: Unit nginx.service has failed

Khades ★★ ()
Ответ на: комментарий от Khades

сделай сервис foo зависящий от nginx и покажи процесс загрузки. Ну и ты проигнорировал более интересные вопросы.

qnikst ★★★★★ ()
Ответ на: комментарий от qnikst

kill -HUP `cat ${pidfile}` &>/dev/null

А потом выясняется, что nginx давно умер, а его PID занят другим процессом, который убивается по SIGHUP =).

Deleted ()

встречаются такие экземпляры, что хочется просто плакать, когда их читаешь

А ты их не читай. Говнокод системдэ не читаешь, вот и их не читай.

rsyslog - программа для организации хранения этих сообщений, полученных по системной шине, реализованной в ядре linux (/dev/log)

journald - легковесный сервис для хранения и чтения логов с хранением их в памяти

Т.е. ради ускорения перезагрузки в среде латентных виндузятников решили пожертвовать надёжностью логгирования? Ну и задница.

ugoday ★★★★★ ()
Ответ на: комментарий от qnikst

на самом деле хз, почему не через s-s-d, который такую ситуацию отлавливает.

Он эту ситуацию никак исправить не может.

Deleted ()
Ответ на: комментарий от qnikst

1). статус openrc - полный ноль

[code]root@debian:/lib/systemd/system# apt-get install openrc
Чтение списков пакетов… Готово
Построение дерева зависимостей
Чтение информации о состоянии… Готово
Package openrc is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'openrc' has no installation candidate
[/code]


2). зачем нужны cgroup, и приплетание их к PID 1

3). высказывание про selinux..

Cgroup включет в себя изоляцию процессов: отдельный namespaces для групп, так, что одна группа не видит процессы, сетевые соединения и файлы другой (копипаста с wiki про идеальное состояние cgroup). Не правда ли напоминает selinux с его доменами? Про пид - просто указание механизма изоляции pid 1 от остальных процессов, а то читал такой бред, что сломанный процесс может негативно влиять на pid 1 вплость до уязвимостей и взлома

Khades ★★ ()
Ответ на: комментарий от Deleted

перед отправлением сигнала он проверяет какая программа висит на том пиде, так что race-condition тут если после проверки, но перед отправкой сигнала nginx успел сдохнуть и его место кто-то занял.. Несмотря на сверхнизкую вероятность данного события оно все же возможно, но без фриза процесса нормально это не решить никак.

qnikst ★★★★★ ()
Ответ на: комментарий от Ford_Focus

и про параметры запуска ты меня очевидно не понял - в ините они задаются с самого начала, прямо под описанием. и использоваться могут много раз по ходу скрипта.

Должны ли они храниться в юнитах? Врядли. Во внешних конфигах? Возможно.

Не стоит всё подряд пихать в systemd и удивляться почему не влезает.

Представилась аналогия - впихивать в mvc-фреймворке во вьюху логику.

Khades ★★ ()
Ответ на: комментарий от Khades

openrc - в тестинге на всех архитектурах, во всяком случае по сообщениям трех дебьянодевов находящихся на #openrc.

Cgroup включет в себя изоляцию процессов:

Какая к черту вики, мы тут из себя специалистов строим или кого? Требуется цитата из /usr/src/linux/Documentation или аналогичного по достоверности ресурса, можно и ссылку на исходники.

Namespaces и cgroups это совершенно не связанные между собой технологии.

qnikst ★★★★★ ()
Последнее исправление: qnikst (всего исправлений: 1)
Ответ на: комментарий от qnikst

перед отправлением сигнала он проверяет какая программа висит на том пиде

Подожди. Он точно узнаёт, что на этом PID висит именно тот nginx или с него хватает соответствия имени?

сверхнизкую вероятность

man закон Мерфи.

race-condition

Даже не отрицаешь, что оно есть.

Кстати, кому принадлежит pid-файл и кто может в него писать? :)

x3al ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.