Зачем нужны системы вроде systemd и почему скрипты запуска демонов такие сложные?

говноini

Чем вам так ini не угодил? Удобный формат для небольших конфигов.

Lennart хотел(хочет) засунуть systemd в зависимости GNOME 3.2

Lennart Poettering: New module ‘libc’ in systemd git

Слияние кодовой базы udev и systemd

Gnome 3.8 под gentoo требует systemd. Что делать?

В systemd предложено включить средства для замены консоли, agetty и /bin/login

Управление пользовательской сессией из systemd

Systemd 207

Этого хватит?

Да ubuntu не осилила даже скрипты перевести на свой upstart

Нет, она дала свободу выбора разработчикам.

То есть этот кусок кода ты написал ничего не читая, не вникая в особенности работы системы инициализации, а прямо так, с потолка?

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

Или это с молоком матери впитывается?

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

Да там же десять типовых строчек.

Чем вам так ini не угодил?

Культурная несовместимость. «Мне лягушку хоть сахаром облепи, не возьму ее в рот» (ц)

Удобный формат для небольших конфигов.

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

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

Большая часть systemd _не нужна_ для указанных кейсов и сделана по причине NIH-синдрома и поцерингита головного мозга. Остальное просто не производит впечатления хорошо спроектированной системы (что косвенно подтверждается ломкой протоколов взаимодействия).

ok, a так?

case "$1" in
start)
  bash /myscript.sh
  ;;
stop)
  kill `cat /tmp/mypid-childs | tr '\n' ' '`
  kill `cat /tmp/mypid`
  ;;
*)
  echo "Usage: $1 [start|stop]"
  exit 1
esac

Угу, с молоком, а точнее с КР. Я же могу скрипт и на С написать, и на похапэ, ну вообщем на том, на чем я разрабатываю, и есть только всего два правила для скрипта/бинаря - обрабатывать параметры запуска типа start stop restart и сделать симлинк на него в /etc/rcS.d/.

Твой ход.

она дала свободу выбора разработчикам.

Давай не будем подменять понятия, очевидно что работа не доделана спустя годы после введения upstart. Как результат, ещё больший бардак: ты никогда не знаешь сработает ли restart apparmor (в 12.04 не сработает). Поэтому проще делать сразу /etc/init.d/apparmor restart . Причём, apparmor это один из ключевых пакетов.

И такой подход прослеживается в убунте во всём. Поэтому я не верю в разрабов убунты.

каждый раз, как вижу это уебищное говноini, вспоминаю NT 4.0.

Ты слишком эмоционально подходишь к вопросу выбора init-системы. Некоторые так же питон из-за отступов ненавидят.

Да у меня очень простой ход: руки оторвать тем разработчикам, которые «всё могут» и при этом ни черта не знают, а чтение документации считают недостойным для себя занятием.

Потому что именно из-за них распрекрасных у нас в /tmp и pid-ы вдруг оказываются, и гигабайтные файлы, которых там по стандарту не должно быть, и restart у половины java-приложений не отрабатывает, оставляя кучу залипших фоновых процессов.

Я всегда делаю /etc/init.d/<что-то> <действие> и у меня все работает. К тому же устанавливается однообразие в обращении с демонами.

каждый раз, как вижу это уебищное говноini, вспоминаю NT 4.0.

Ты слишком эмоционально подходишь к вопросу выбора init-системы

Высказанные эмоции относились конкретно к ini, а не init-системе. Естественно, мне неприятно видеть вендовый формат в самом сердце Linux-системы, не вижу ничего «слишком».

К тому же устанавливается однообразие в обращении с демонами.

Угу. Возникает вопрос зачем тогда делали комманды start, stop, restart и status раз они работают через раз.

Я об этом и говорю, бросили миграцию на половине пути.

Вот и я о том же — для большинства юзеров основная проблема с systemd не в том что оно плохо работает (и такое бывает, баги там есть), а в том что «им неприятно». Но это уже вопрос из другой области. Впрочем, тема как раз для толксов.

Этого хватит?

Убедил.

Вот и я о том же — для большинства юзеров основная проблема с systemd не в том что оно плохо работает

Я не юзер systemd и уже сказал - меня не волнуют ошибки в нем. Меня волнует, что базовый системный компонент делается с демонстративным нарушением принципов самой системы, при этом он еще и внутри сделан убого.

description "My service"
start on runlevel [2345]
exec ./myscript.sh

Это из мира upstart.

Большая часть systemd _не нужна_ для указанных кейсов

Ок. Назови ненужные части системде для указанных кейсов

Назови ненужные части системде для указанных кейсов

Широко разрекламированная сокетная активация, journal, control groups, systemd-nspawn. Ах да... и встроенный DHCP-клиент.

Широко разрекламированная сокетная активация, journal, control groups, systemd-nspawn. Ах да... и встроенный DHCP-клиент.

Большая часть systemd

Ололо.

Ну, в целом я с тобой согласен - DHCP клиент нужен арчеводам, им без него плохо лол; systemd-nspawn - нужен Леннарту, что бы отлаживать системде.

По поводу control groups ЯННП, что ты хотел сказать.

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

По поводу журнала - такой кейс, как агрегация информации по заданным критериям с определенным апи, он покрывает.

Большая часть systemd

Ололо.

Что такое - это все малая часть systemd?

По поводу control groups ЯННП, что ты хотел сказать.

Что их использование при запуске служб не нужно для $YOUR_USECASES.

По поводу журнала - такой кейс, как агрегация информации по заданным критериям с определенным апи, он покрывает.

Такого кейса не было в $YOUR_USECASES. Но, конечно, можно выписать всё, что умеет systemd, и вопрошать «назови ненужные для этих кейсов части systemd».

Что их использование при запуске служб не нужно для $YOUR_USECASES.

Они используются при остановке служб. Так можно туда запихать какие-нибудь другие наборы слов, например «inotify, sysfs, efivarfs» итд.

Такого кейса не было в $YOUR_USECASES

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

RH такие же перепаковщики, как и Debian

Не такие же, у них как минимум есть деньги и сотрудники работающие за зарплату.

Что их использование при запуске служб не нужно для $YOUR_USECASES.

Они используются при остановке служб.

Службы 20 лет запускались без этого и останавливались тоже,

можно туда запихать какие-нибудь другие наборы слов, например «inotify, sysfs, efivarfs» итд.

Еще раз: ты привел список кейсов, я ответил _по нему_. И, хотя я не знаю, что такое efivars, я думаю, что для приведенного тобой списка кейсов они не нужны.

Сейчас ты постепенно начинаешь расписывать, что systemd умеет - так претензия в том, что он умеет слишком много всего, и останавливаться на этом не собирается.

Вменяемый централизованный механизм агрегации логов позволит вываливать эти самые логи сразу в нужном месте.

Вот вечно так - на вопрос «почему $X сделано именно так?» начинают расписывать, какое щастье наступает от этого $X.

Ты собеседником ошибся ))

Упс. Сорри.

Службы 20 лет запускались без этого и останавливались тоже,

Ты действительно не видишь разницу между «остановить все процессы, порожденные службой», и «если повезет, остановить процесс службы»?

Еще раз: ты привел список кейсов, я ответил _по нему_.

Ты упомянул технологию/решение, а не фичу системде, что вызвало у меня недоумение.

Сейчас ты постепенно начинаешь расписывать

.. утрированный список слов для примера неадекватности употребления cgroups в том контексте

Вот вечно так - на вопрос «почему $X сделано именно так?» начинают расписывать, какое щастье наступает от этого $X.

Есть мнение, что «$X сделано именно так», для озвученного счастья

ну ...
заглянем в историю, да ?)
RH уже нам подарила одно дарование - David Zeuthen - автор hal,DeviceKit, Polkit . Есть у всех этих проектов одно общее - хреновая документация и некая склонность к насильному их внедрению именем RH. Также оно и сдохло от народной любви, скажем так ))
Зачем на грабли наступать еще раз ?

Не ошибается тот, кто ничего не делает.

Верно.
А по какому праву RH приватизировал право на ошибку ?)
В некотоых вопросах бездействие более выгодно активных действий.
Fedora и Centos подопытный полигон для куловодов RH.
Что, этого мало уже ?
Марк, например, не впаривает свое юнити всем ?
Ну не умеет RH продвигать технологии в сообществе.
Ничего страшного, переживем как-то и это)

Марк, например, не впаривает свое юнити всем ?

Ну, это проблематично. Потому что для юнити нужно обкостылять gtk стек. Тут история похожа на гном+системде

Ты действительно не видишь разницу между «остановить все процессы, порожденные службой», и «если повезет, остановить процесс службы»?

Я вижу, что мне постоянно везет.

Ты упомянул технологию/решение, а не фичу системде, что вызвало у меня недоумение.

И ты не догадался, что имелось в виду использование этой технологии в systemd? Ну, бывает.

Вот вечно так - на вопрос «почему $X сделано именно так?» начинают расписывать, какое щастье наступает от этого $X.

Есть мнение, что «$X сделано именно так», для озвученного счастья

Ага. Еще хороший ответ «для продажи». То, что это ответы не на заданный вопрос, неважно. Главное - эффектно.

Ну не умеет RH продвигать технологии в сообществе.

Это ты в треде про systemd пишешь? Ну-ну.

Сюрприз, unit для systemd останется тем же самым - он по-умолчанию при остановке сервиса, останавливает и его child-процессы. Если это не нужно (что бывает нечасто, то в unit-файле нужно указать KillMode=process). Продолжим?

Ну-да.
А какого рожна всех федорастов колбасит «а пролезет ли их поделие в деб ?»
Коллективный дух вредительства? Cродни «а почему все не роликовые
релизы ?»
Нипорядок, надо мозги долбить им всем.
Мне же так удобно ... ну просто не передать словами.))

У арчеводов был rc.conf.

Вот в том и то вопрос, что в любом Linux-дистрибутиве ini-конфигов куча, а он к systemd почему-то прицепился. По мне так ini для такого рода конфигураций почти идеал, в отличие от какого-нибудь там xml

Ну а это - просто поток несвязного бреда.

У молодых это называется «нераспарсил, шито ?»
типа , некое перманентное затупление незамутненного хитросплетениями сознания.)

не вижу ничего общего в твоих высказываниях с системой инициализации.

Описанный тобой случай - частность. Работает так только если родительский и дочерний процесс в одной cgroup'е. А в типичном случае они не будут в одной группе, т.к. только форкнутые процессы наследуют группу (насколько я помню, но могу конечно же быть не прав немного), либо мастер процесс должен самостоятельно озаботиться о группе дочернего процесса. Давай более рабочий вариант.

в типичном случае они не будут в одной группе

Не согласен, как-раз таки обычно в одной.

Давай более рабочий вариант.

А давай возмем какой-нить реальный сервис на твой выбор и сравним скрипт и юнит-файл, а то как-то абстрактный сервис как-то глупо сравнивать.

Не согласен, как-раз таки обычно в одной.

«обычно»? Обоснуй, ну либо подтверди хотя бы примером с кодом. Я пересмотрел доку по сигрупам, там написано что наследуется группа только для форкнутых процессов...

А давай возмем какой-нить реальный сервис на твой выбор и сравним скрипт и юнит-файл, а то как-то абстрактный сервис как-то глупо сравнивать.

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

Я вообще за старый добрый bsd init. В принципе, в описываемом виде systemd - современная и сложная ПРЯМАЯ замена элементарному скрипту автозапуска + inetd.

Попаболь, связанная с зависимостями: shell скрипт выполняется последовательно, потому то, что запущено позже, будет запущено ПОСЛЕ того, что должно быть запущено раньше

Попаболь, связанная с «ой-ой, ВНЕЗАПНО упал демон, надо перезапустить» - вообще ГНИЛАЯ. Или демон работает, или падает ВСЕГДА, пока не устранена причина падения. НИКАКОЙ systemd не поможет его нормальной работе.

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

Попаболь, связанная с зависанием чайлдов головного процесса демона... ОТЛИЧНАЯ идея! Криворуко написанный демон, в котором потомок «уходит» от родителя и после завершения родителя не ловит сигнал о собственном завершении - так вот проблема такого демона именно в init системе, и ни в чём больше! И только замена init на более сложный спасёт ситуацию (а не написание прямого софта).

Проблема не в том, что systemd сложный или кривой, проблема в том, что он решает не существующие проблемы и усугубляет существующие.

Более того, большая часть проблем решается созданием какой-нибудь libdaemon.so, повышающей качество и культуру написания демонов.

Нет, надо лезть в init. И жуткую ненависть вызывают как раз такие принципы: демон pulseaudio вместо допиливания soft mixerа (как делалось везде, во всех системах и дистрибутивах linux, кроме rh), изменение init вместо повышения качества программного кода... Предсказываю, что следующей инновацией от Поттеринга будет замена grub для обеспечения работы устройств ввода (клавиатур, мышей и т.п.) и замена gcc для «правильного» видеоускорения.

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

[Unit]
Description=My Script
[Service]
ExecStart=/myscript.sh
ExecStopPre=/sbin/kill `cat /tmp/mypid-childs | tr '\n' ' '`
[Install]
WantedBy=multi-user.target

Это, к слову, к тому, что если очень хочется добавлять свои скриптовые штуки для/вместо start/stop в systemd, то никто и не мешает. Но я почему-то уверен, что для реальных демонов такое будет нужно очень редко.

Предлагаю продолжить таки с более реальными кейсами - ты скрипт для sysvinit, я systemd юнит. Думаю, что после 3-5 примеров станет понятно, что проще и читабельнее.

Угу, ну кароче тада это, давай скрипт сервиса для ссшд и апач2 :=) Вродь класические такие сервисы.

Держи:

apache2:

[Unit]
Description=Apache Web Server
After=network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
PIDFile=/run/httpd/httpd.pid
ExecStart=/usr/bin/apachectl start
ExecStop=/usr/bin/apachectl graceful-stop
ExecReload=/usr/bin/apachectl graceful
PrivateTmp=true
LimitNOFILE=infinity

[Install]
WantedBy=multi-user.target

sshd:

[Unit]
Description=OpenSSH Daemon
Wants=sshdgenkeys.service
After=sshdgenkeys.service
After=network.target

[Service]
ExecStart=/usr/bin/sshd -D
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=always

[Install]
WantedBy=multi-user.target

sshdgenkeys.service просто проверяет наличие ключей в /etc/ssh/ и генерит их, если их там нет, вот его содержимое:

[Unit]
Description=SSH Key Generation
ConditionPathExists=|!/etc/ssh/ssh_host_key
ConditionPathExists=|!/etc/ssh/ssh_host_key.pub
ConditionPathExists=|!/etc/ssh/ssh_host_ecdsa_key
ConditionPathExists=|!/etc/ssh/ssh_host_ecdsa_key.pub
ConditionPathExists=|!/etc/ssh/ssh_host_dsa_key
ConditionPathExists=|!/etc/ssh/ssh_host_dsa_key.pub
ConditionPathExists=|!/etc/ssh/ssh_host_rsa_key
ConditionPathExists=|!/etc/ssh/ssh_host_rsa_key.pub

[Service]
ExecStart=/usr/bin/ssh-keygen -A
Type=oneshot
RemainAfterExit=yes

systemd - это не альтернатива init. Это нечто гораздо большее.

systemd - это не линукс. Как и андроид. Ты «не хотел говорить это сам»?