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

★★

Последнее исправление: Khades (всего исправлений: 7)

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

Khades> Дописав ещё пару десяток строчек в каждый файл в /etc/init.d

Зачем?

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

Отладка SystemD.

HINT: Keep a copy of /sbin/init from sysvinit package in case of rescue (so you can use init=/sbin/init.sysvinit in cmdline)!

Archer73
()
Ответ на: комментарий от der_looser

А это идея. Надо Леннарту предложить.

Quasar ★★★★★
()

Забыли рассказать, что вся эта заварушка началась с жёсткой зависимости новых версий GNOME от systemd-logind.

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

уровень индиффириентности к гному по крайней мере у меня - 100%

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

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

Нет, потому что статус службы перейдет в crashed(скорее всего openrс хранит имя запущенного процесса в дополнение к PID, но тут не уверен). Поэтому даже если появится другой процесс с таким же PID, reload на него выполнить не удастся, только zap.

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

тогда это будет уже не ini, а странный страшный гибрид. впрочем, Леннарт любит что-то такое говнистое.

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

юниты systemd не скрипты, а конфиги. и положить в них какую-то логику принципиально не получится.

Доо. Там вполне есть Exec*.

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

вроде в трэде уже говорили, что эти Exec - лишь ссылки на внешние файлы (которые могут быть хоть бинарями), а не аналог логики в ините.

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

вроде в трэде уже говорили, что эти Exec - лишь ссылки на внешние файлы

Эти Exec*, когда я смотрел в последний раз, были местами, в которые можно вписать маленькие скрипты. Если это не «логика», то что же такое «логика»?

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

сколько я смотрел примеры и существующие иниты - везде были ссылки на внешние файлы. можно пример обратного?

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

везде были ссылки на внешние файлы

И... это доказывает, что внешний файл не содержит логику?

можно пример обратного?

man systemd.service:

Example:

               ExecStart=/bin/sh -c 'dmesg | tac'
tailgunner ★★★★★
()
Ответ на: комментарий от Ford_Focus

/bin/sh -c 'dmesg | tac'

что является ссылкой на внешний бинарь

Кхм. Вообще-то shell-выражение, использующее 3 внешних бинаря. И shell-выражение может быть любым.

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

это именно вызов бинаря sh c параметром. и писать сколько угодно весомый скрипт в параметре к бинарю - извращение еще похлеще ссылки на внешный файл.

я предпологал, что systemd-фаги странноваты, но не знал, что до такой степени.

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

это именно вызов бинаря sh c параметром

Ты правда не понимаешь, что такое shell-выражение? Окей.

я предпологал, что systemd-фаги странноваты, но не знал, что до такой степени.

Ты везде ошибся, бывает.

tailgunner ★★★★★
()

Вот пример сервиса с параметром

[Unit]
Description=OpenVPN Robust And Highly Flexible Tunneling Application On %I
After=syslog.target network.target

[Service]
PrivateTmp=true
Type=forking
PIDFile=/var/run/openvpn/%i.pid
ExecStart=/usr/sbin/openvpn --daemon --writepid /var/run/openvpn/%i.pid --cd /etc/openvpn/ --config %i.conf

[Install]
WantedBy=multi-user.target

Например у меня есть в /etc/openvpn конфиг для рабочей сетки lidabeer.conf Я запускаю openvpn просто вот так: sudo systemctl start openvpn@lidabeer ну и на постоянку включил так sudo systemctl enable openvpn@lidabeer.

Как такое делается в других системах управления службами?

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

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

++

quest ★★★★
()

Да про баш ты прав. Да systemd крут и он должен убрать эту фрагментацию в линупсе. Но даже он не решает проблему запуска поганых java сервисов, которые в свою очередь работают через поганые баш скрипты.

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

я твои свежепридуманные базворды не понимаю и как-то не очень хочу понимать

Argument List Processing

-c Read commands from the command_string operand instead of from the standard input.

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

если инит на php, то

if ($argv[1]) {$StartUpCommand.="--config $argv[1].conf"}
запускать
/etc/init.d/openvpn start lidabeer

//shell не люблю и не знаю, код на нём привести не могу

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

я твои свежепридуманные базворды

Они мои не более, чем твои.

не понимаю и как-то не очень хочу понимать

Учись, студент. В жизни пригодится.

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

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

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

это твоё, свежепридуманное. выхлоп твоего бредогенератора

/me молча пожал плечами и добавил комментарий к нику.

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

В опенрц делается точно также, посмотри openvpn и net, причём задолго до системы, я помню как ещё над системдфанами можно было смеяться что этой функциональности нет.

А теперь интересный вопрос, как переопределить часть опций для конкретного %i, напр добавить лимиты?

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

Прямо никак. Или в конфиге самого соединения, или просто создав в /etc/systemd/system/ файл с полным названием и переопределив некоторые параметры.

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

Создание файла в /etc/systemd стандартная практика. Например, мне нужно было добавить в http несколько переменных окружения.

Так я просто создал файл такого содержания:

.include /lib/systemd/system/httpd.service
[Service]
Environment=TNS_ADMIN=/usr/lib/oracle/11.2/client64/lib

И всё. Может такое кому-то не удобно, по сравнению с прямым редактированием shell скрипта, но мне вполне хватает.

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

А в опенрц - как

Это разве плюс? Ну то есть весь смысл этого параметризованного юнита - вынести параметры из собственно логики запуска.

или создаешь конф файл сервис.и.конф

а для этого и в systemd есть EnvironmentFile или как его там

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

Дык в опенрц разделение логика, которая может сильно меняться в зпвтсимости от параметром (что не выразишь декларативным ини файлом, правда это редко) и файл конфига, где живут все опции. В системД аналогом является переопределение юнитов и наследование базового файла, тоже ничего (при наличии утилиты показывающей где что изменено и переопределено (которая есть))

qnikst ★★★★★
()
Ответ на: комментарий от qnikst
user > srv cat test@test2.service
# ~/.config/systemd/user/test@.service
[Unit]
Description=Just Test

[Service]
Environment=BLAH=BAH
ExecStart=/bin/sh -c 'echo $BLAH: %i >/tmp/test.out'

# ~/.config/systemd/user/test@test2.service.d/00-override-env.conf
[Service]
Environment=
Environment=BLAH=WUT
user > srv daemon-reload                                                              
user > srv start test@test.service 
user > cat /tmp/test.out          
BAH: test
user > srv start test@test2.service
user > cat /tmp/test.out           
WUT: test2
user > 
vasily_pupkin ★★★★★
()
Ответ на: комментарий от qnikst

В системД аналогом является переопределение юнитов и наследование базового файла, тоже ничего (при наличии утилиты показывающей где что изменено и переопределено (которая есть))

На самом деле ето deprecated (%

Сейчас параметры переопределяются заплатками drop-in, показывает сам systemctl:

user > systemctl status sshd   
sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib64/systemd/system/sshd.service; enabled)
  Drop-In: /etc/systemd/system/sshd.service.d
           └─disable-tpm.conf
   Active: active (running) since Ср 2014-02-12 08:04:44 EET; 6 days ago
 Main PID: 2253 (sshd)
   CGroup: /system.slice/sshd.service
           └─2253 /usr/sbin/sshd -D -e

фев 12 08:04:44 WinterMute systemd[1]: Starting OpenSSH server daemon...
фев 12 08:04:44 WinterMute systemd[1]: Started OpenSSH server daemon.
фев 12 08:04:44 WinterMute sshd[2253]: Server listening on 0.0.0.0 port 22.
фев 12 08:04:44 WinterMute sshd[2253]: Server listening on :: port 22.
user > systemctl cat sshd   
# /usr/lib64/systemd/system/sshd.service
[Unit]
Description=OpenSSH server daemon
After=syslog.target network.target auditd.service

[Service]
ExecStartPre=/usr/bin/ssh-keygen -A
ExecStart=/usr/sbin/sshd -D -e
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/sshd.service.d/disable-tpm.conf
[Service]
Environment=TPM_ENABLED=disabled

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

Смотрите шырше. Все параметры переопределяются, я Environment для примера нарисовал.

vasily_pupkin ★★★★★
()

1) Почему systemd должен упасть?

pulseaudio же падает.

2) Ядро тоже падает, давайте все ненавидеть ядро

Если есть одно слабое звено, то это не повод вводить ещё одно.

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

Ну вот, например:

user > srv daemon-reload                                                                               
user > srv start test@test.service                                                                     
user > cat /tmp/test.out                                                                               
10
user > srv start test@test2.service
user > cat /tmp/test.out           
unlimited
user > srv cat test@test2.service
# ~/.config/systemd/user/test@.service
[Unit]
Description=Just Test

[Service]
LimitCPU=10
ExecStart=/bin/sh -c 'ulimit -t >/tmp/test.out'

# ~/.config/systemd/user/test@test2.service.d/00-override-env.conf
[Service]
LimitCPU=infinity
user > 
vasily_pupkin ★★★★★
()

Перевод моей критики systemd на reddit'е

Предположим все дистрибутивы соберут systemd с флагами --disable-qrencode --disable-microhttpd и мне не надо будет говорить про влияние диссертации некего брата на ключевые компоненты системы. Посмотрим на реальные недостатки.

1. Всё прибито гвоздями. Это не моё мнение, это официальная позиция авторов: http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabi... logind отдельно не переписать, journald «Maybe». Да даже «Unit file format» с какого-то перепугу объявлен приватным. Это - плохой дизайн.

2. Декларативный синтакс ini-файлов только скрывает сложность решаемой задачи. Надо будет решить что-то нестандартное и останется только стучаться в стену. Те кто писал на java с maven прекрасно знают о чём я говорю. java программисты закопали maven, теперь линуксоиды радостно бросились в ту же пропасть.

3. Бинарные логи. Да ещё с внутренней организацией что б разные части лога были за-mmap'лены по-разному. Конец у нас transaction log, поэтому append-only, а середина индексы, поэтому изменяема. До нас эту задачу не решал никто, надо свой новый формат придумывать, конечно. Документированные на уровне C-структур только, нда...

4. API никто не дизайнил вообще, самро выросло из реализации кое-как. Например mount и automount это у нас разные типы юнитов, зато все сервисы свалены в один тип юнитов «service», а чтобы их отличать введён аттрибут «Type» («oneshot», «forking»). Если бы систему кто-то проектировал, то либо был бы один тип юнита mount с под-типами «auto» и «manual», либо сервисы были бы раскиданными по разным типам юнитов. А так в одном месте одно решение, в другом другое, в результате - каша.

5. Качество кода. Я взял дефолтное действие основной пользовательской утилиты systemctl и проследил за её исполнением. По ходу встретил неоткомментированную функцию сортировки юнитов (в недокумментированном порядке) и одну замечательную проверку, которая позволяет иметь в системе скрытые от админа сервисы (привет руткитам!). Тоже, естественно, без комментариев: http://cgit.freedesktop.org/systemd/systemd/tree/src/core/dbus-manager.c#n708

Некий девелопер наговорил кучу красивых слов как всё правильно надо сделать и всех убедил. Идеи и правда хорошие. Но вот код он писать НЕ УМЕЕТ. И проектировать ПО тоже. Пусть будет гуру, идеологом, кем угодно. Но вот код, который он пишет, нужно за ним весь переписывать как положено. А не включать в ведущие репозитории по-умолчанию.

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