в современных реалиях он абсолютно бесполезен

Сколько тебе лет?

Представь себе, помимо ПК в мире есть и другие места применения Linux.

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

Ошибка в том что необходима некая прослойка. Это как с pulseaudio - удаляешь и всё сразу становится хорошо.

Разница с пульсаудио весьма наглядна. У нее аналог alsa, которая может 80% всего что нужно из коробки. И то, безпроблемный мультисит на алсе уже не так легко сделать.

А в случае системд, альтернатива - тонна лапши на баше. Что однозначно не айс.

тонна лапши на баше. Что однозначно не айс.

Большинство пользователей десктопного линукса эту «лапшу» никогда в глаза не видели и отлично, знаете ли, у них всё работало. Если же вам нужно от ПК несколько больше, то не осилить баш как то даже стыдно, «тонна лапши» элементарно читается по диагонали с полным пониманием происходящего.

Ты специально игнорируешь всё, кроме тех двух слов, на которые ты придумал, что ответить?

За тред по меньшей мере пять раз было сказано, что «ускорение загрузки» не является основным или даже второстепенным преимуществом systemd. Это самое «ускорение» носит характер приятного бонуса, вытекающего из идеи расстановки зависимостей между задачами.

Скорость загрузки никогда не была хорошим аргументом, т.к. перед sysvinit такую задачу разработчики себе не ставили. Ибо кому какая разница, 5 секунд или 3. Примерно в 12м году я проставил пару бекграундов в init скриптах и скорость была не меньше, чем с systemd.

Никого не смущает, что target network и network-online не означают работающую сеть в systemd? А когда Вам в юните нужно запускать процесс только после того, как сеть заработала приходится... запускать в юните bash скрипт!

Нафига тогда меняли?

Да и куча других с ним проблем в продакшене, увы. Например плевать он хотел на /etc/security/limits.conf. Выставляешь там nofile 65k, проверяешь процесс - все ок. Рестартанул юнит - всё упало, всё пропало. По опыту понимаешь, что скорее всего systemd подосрал. Проверяешь - действительно, оказывается в юните нужно указывать LimitNOFILE=65000. В голове три вопроса. Почему разработчики pam не выпилилсь? Уберите тогда из /etc/security что бы людей в заблужение не вводить.. Почему новый модный формат, а не наследование из общепринятого места? Почему дистростроители это приняли к себе? В общем много почему... Приняли говно, теперь предется еще много лет подчищать.

Ну и в заключение - мой ноут он просто не умеет выключать. Т.к. не может отмонтировтаь luks, в итоге он сперва 15 секунд пытается отмонтировать, потом 30 секунд, потом 45.. и так вечено. Почему такое стандартное поведение? Уже вижу как в проде отправил сервер в ребут и сразу заказал kvm в ДЦ)) (Я конечно понимаю, что где-то у меня косяк, но то что выключается сеть, выключается все, а комп висит на вечном отмонтировании - это беспредел.)

Большинство пользователей десктопного линукса эту «лапшу» никогда в глаза не видели и отлично, знаете ли, у них всё работало. Если же вам нужно от ПК несколько больше, то не осилить баш как то даже стыдно, «тонна лапши» элементарно читается по диагонали с полным пониманием происходящего.

Дак большинство пользователей и системд не видят в глаза.

А если от ПК нужно несколько больше... К примеру сервер терминалов, то без системд с его удобным управлением сессиями, ситами, нормальным распределением ресурсов и прочими ништяками не обойтись.

Никого не смущает, что target network и network-online не означают работающую сеть в systemd?

Ну хз, сколько не экспериментировал, network-online всегда выполнялся после конфигурации сети.

Например плевать он хотел на /etc/security/limits.conf.

Тоже как-то столкнулся. Эт да, могли-бы от туда прочитать как дефолт для пользователей/групп.

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

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

Тоже сталкивался, правда с вечным отмонтированием NFS... Не помню как решил, оно чуть-ли не само после апдейда решилось.

неправильно противопоставляете - тонна лапши на баше против двух тонн лапши на Си. На opennet прекрасная табличка была. Так что аргумент с “лапшой” уже выступает как раз против systemd.

Ты забыл в первом случае учесть объём кода интерпретатора bash и утилит из coreutils/util-linux.

Ну и да, «лапша на Си» в составе systemd написана единожды, а «лапша на bash» переписывается каждым дистрибутивом и каждым инитскриптописателем заново.

объём кода интерпретатора bash и утилит из coreutils/util-linux.

Лёня и это скоро выкинет? bashd, coreutilsd и интерпретатор visual basic войдут таки в systemd.

вот таблица о которой говорено: https://www.opennet.ru/openforum/vsluhforumID3/107695.html#47

Ты забыл в первом случае учесть объём кода интерпретатора bash и утилит из coreutils/util-linux.

А что systemd уже coreutils поглотил? мама-миа….

Ну и да, «лапша на Си» в составе systemd написана единожды, а «лапша на bash» переписывается каждым дистрибутивом и каждым инитскриптописателем заново.

А юниты сами по себе в дистрибутивах оказываются...

А что systemd уже coreutils поглотил? мама-миа….

Очевидно, я говорю о суммарном объёме кода, который «затрагивается» в процессе загрузки.

А юниты сами по себе в дистрибутивах оказываются...

А юниты — это не лапша. Там нет избыточности.

Очевидно, я говорю о суммарном объёме кода, который «затрагивается» в процессе загрузки.

Ну вот в случае bash затрагивается 100К кода, а на systemd 270K - разница в ДВА РАЗА, КАРЛ!

А юниты — это не лапша. Там нет избыточности.

https://www.opennet.ru/openforum/vsluhforumID3/108006.html#149

#!/bin/sh
#
# $OpenBSD: postgresql.rc,v 1.11 2014/09/23 08:41:10 sthen Exp $

datadir="/var/postgresql/data"

daemon="/usr/local/bin/pg_ctl"
daemon_flags="-w -l /var/postgresql/logfile"
daemon_user="_postgresql"

. /etc/rc.d/rc.subr

rc_usercheck=NO

rc_check() {
        ${rcexec} "${daemon} -D ${datadir} status"
}

rc_reload() {
        ${rcexec} "${daemon} -D ${datadir} reload"
}

rc_start() {
        rm -f ${datadir}/postmaster.pid
        ${rcexec} "${daemon} -D ${datadir} start ${daemon_flags}"
}

rc_stop() {
        ${rcexec} "${daemon} -D ${datadir} stop -m fast" || \
                ${rcexec} "${daemon} -D ${datadir} stop -m immediate"
}

rc_cmd $1

Ну вот в shell тоже ок, как видим. Причём руки никто не связывает, в отличие от единого рассово-верного пути, которому вас обучат на корпоративных курсах красношапки за 3К вечнозелёных.

Ну вот в случае bash затрагивается 100К кода

Повторяю во второй раз: ты не учёл объём кода вспомогательных утилит, которые в случае systemd не используются.

Ну вот в shell тоже ок, как видим

rm -f ${datadir}/postmaster.pid

Ога. А теперь добавь мне сюда проверку того, что все точки монтирования для ${datadir}, объявленные в fstab, примонтировались. Или авторестарт при падении. Или запихни все процессы постгреса в mount namespace, чтобы ему был виден только его рабочий каталог.

А ещё лучше — покажи инитскрипт для какого-нибудь демона без встроенных команд start и stop, которые внутри себя реализуют все проверки и коммуникацию с имеющимися инстансами (т. е. всё то, что уже умеет делать systemd для всех и забесплатно).

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

Причём руки никто не связывает, в отличие от единого рассово-верного пути

Я не имею понятия, кто кому в твоём представлении «связывает руки» и навязывает «единый расово верный путь». В systemd с этим проблем никаких.

Повторяю во второй раз: ты не учёл объём кода вспомогательных утилит, которые в случае systemd не используются.

Конечно зачем использовать проверенный и простой код в утилитах, если можно сделать свой велосипед с квадратными колёсами, так ведь?

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

Конечно зачем использовать проверенный и простой код в утилитах, если можно сделать свой велосипед с квадратными колёсами, так ведь?

Не стоит спрыгивать с темы. Ты прокукарекал, что systemd раздут даже по сравнению с башем. Я показал, что твой аргумент некорректен, потому что баш сам по себе (без coreutils/util-linux) ничего не может. Всё.

Ах да, ещё я забыл, что товарищ с опеннета мерял объём кода в репозитории systemd, а там помимо PID 1 лежит ещё много всего. Так что сравнение дважды некорректно, с чем я тебя и поздравляю.

Ты прокукарекал

Уровень собеседника очевиден, вопросов больше нет.

а «лапша на bash» переписывается каждым дистрибутивом и каждым инитскриптописателем заново.

глянул у себя в системе: rc.cups взят бородатых годов, копирайт Apple/Easy Software Products, под HP-UX, AIX, SINIX, IRIX, UnixWare, *BSD, Darwin, Linux.

SystemD еще штопать и штопать.

«Нет аргументов — до5.1сь до формулировки»

Окей, я слегка не то написал. Важно не то, кем инитскрипт был изначально написан, а то, что в каждом дистре есть своя ни с кем не совместимая его копия.

Ну и в любом случае для каждого демона это всё пишется заново или почти заново.

Не стоит спрыгивать с темы. Ты прокукарекал, что systemd раздут даже по сравнению с башем. Я показал, что твой аргумент некорректен, потому что баш сам по себе (без coreutils/util-linux) ничего не может. Всё.

Зафиксировано “Ой всё” на запрос конкретных утилит :D

P.S. А “кукарекать" на зоне будешь на своём месте.

Если ты обладаешь достаточной компетенцией для того, чтобы спорить про иниты — то strace'нуть процесс загрузки и погрепать лог по слову '^execve\(' ты и подавно должен уметь.

diff в студию

Удваиваю. Скатывание дискуссии в площадку для самоутверждения ещё участников всякими «прокукарекал» явно хуже «некорректных аргументов», которые он тут обличает.

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

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

А можешь привести пример пожалуйста, что именно bash не может без coreutils именно в разрезе задач инит скриптов. Я пока только mkdir придумал, без которого в общем-то можно обойтись. Что еще?

Нет, т. к. речь идёт об операциях 1) проверки запущенности демона и 2) остановки всех процессов демона. Эти операции отлично обобщаются.

Окей, я слегка не то написал

И дальше ты снова не то пишешь:

Важно не то, кем инитскрипт был изначально написан,

Я ответил примером, опровергающим

а «лапша на bash» переписывается [skip] каждым инитскриптописателем заново.

Не переписывается.

«лапша на bash» переписывается каждым дистрибутивом

Не переписывается.

в каждом дистре есть своя ни с кем не совместимая его копия.

Ты чем читаешь? Я тебе сказал, что у меня в системе скрипт, написанный мэни ирс эго, и совместимый с целым рядом операционных систем. Что ты несёшь?

Ну и в любом случае для каждого демона это всё пишется заново или почти заново.

Да, для каждого демона нужен rc скрипт. Какая новость! То ли дело SystemD. Сам пишет service файлы)

«Что bash не может» или «без чего bash не используют»? Пример: да, можно итерироваться по /proc/* на чистом баше и считывать свойства процессов с помощью конструкции $(< ... ), но любой человек в здравом уме будет использовать ps, pgrep и pidof.

Я понимаю, что в инит скриптах злоупотребляют каким-нибудь ps, cat, sed чем-нибудь таким. Но серьезно не вижу никаких причин почему бы не реализовать все эти же функции на баше и подсорсить к инит скриптам, раз уж мы говорим о зависимостях. Иными словами концептуально от зависимостей можно было бы избавиться, но нам всем, конечно, понятно, что в рядах sysvinit не нашлось столь упортого человека, который переписал бы ps на баше.

Да, для каждого демона нужен rc скрипт

Да, для каждого демона нужен инитскрипт, сложность логики в котором прямо пропорциональна развесистости демона и обратно — интенсивности NIH-синдрома демонописателя, когда он заново писал для своего демона команды start/stop/restart со всеми нужными проверками и IPC.

Нет, т. к. речь идёт об операциях 1) проверки запущенности демона и 2) остановки всех процессов демона. Эти операции отлично обобщаются.

Демон не в курсе что он назапускал? и с bash никоим образом не определить запущен ли демон? 0o0

Если кто-нибудь так сделает, то sysvinit+обвязка по количеству кода на C действительно сравняется с systemd (замечу, в последнем количество кода, которое непосредственно участвует в процессе загрузки, гораздо меньше 200 kLOC).

Да, для каждого демона нужен инитскрипт, сложность логики в котором прямо пропорциональна развесистости демона и обратно — интенсивности NIH-синдрома демонописателя, когда он заново писал для своего демона команды start/stop/restart со всеми нужными проверками и IPC.

А что делать с NIH-синдромом создателя systemd?

Сдаётся мне что наш друг Ваня употребил внутрь смелой воды и не ведает что пишет.

Ты уж определись, какую точку зрения ты отстаиваешь: надо писать все проверки в инитскрипте или непосредственно в коде демона, чтобы наружу торчали готовые start/stop/status, как с постгресом?

Короче, в случае sysvinit эту логику всё равно где-нибудь придётся дублировать. В случае systemd — нет.

В результате NIH-синдрома создателя systemd получилось нечто, обладающее разнообразными преимуществами относительно prior art. В таких случаях говорят, что переизобретение оправдано.

Так NIH-синдром плох или хорош?

P.S. Вот уже девять сотен сообщений от людей “оценивших” этот пример современного нигилистического творения …. Ох… убью себя фейспалмом чувствую.

А давай приведём менее искусственный пример?

/etc/init.d/fcgiwrap: http://pastebin.com/33AAb7Pk

Два юнита:

[Unit]
Description=Simple CGI Server
After=nss-user-lookup.target
Requires=fcgiwrap.socket

[Service]
Environment=DAEMON_OPTS=-f
EnvironmentFile=-/etc/default/fcgiwrap
ExecStart=/usr/sbin/fcgiwrap ${DAEMON_OPTS}
User=www-data
Group=www-data

[Install]
Also=fcgiwrap.socket

[Unit]
Description=fcgiwrap Socket

[Socket]
ListenStream=/run/fcgiwrap.socket

[Install]
WantedBy=sockets.target

разработчики демона лучше знают как с ним обращаться

Я так понял, разработчики почтовых серверов, например, этого просто не знают? Очень редко можно увидеть аналог pg_ctl.

Вызывает большие сомнения в адекватности некоторых дискутирующих попытки сравнения размеров инит-скриптов и утилит сопровождения при наличии ГИГАБАЙТ ОЗУ даже на самом убогом, навозом покрытом в три слоя ПК. Учитывая, что эти скрипты работали ещё на sco unix open server и solaris ещё в далёких 90-х и никто не страдал от их размера, то сейчас такие аргументы просто смехотворны.

Missing the point. Мы говорим не о ресурсоёмкости, а о сложности сопровождения.

Ой как некрасиво обманывать... А это что? Релиз systemd 230 (комментарий)

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

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

bash и coreutils не нуждаются в поддержке.

bash и coreutils не нуждаются в поддержке

Это которые GNU? Не нуждаются? Это тот bash, который решето из-за низкого качества кода? Это те Coreutils, в которых в 2016-ом неконсистентная поддержка UTF-8? Ну-ну :)

Хорошо, буде предельно корректен, нуждается в поддержке, но где то 1 человекочас в год.

неправильно противопоставляете - тонна лапши на баше против двух тонн лапши на Си. На opennet прекрасная табличка была. Так что аргумент с “лапшой” уже выступает как раз против systemd.

К тонне лапши на баше добавьте с десяток тон «лапшы» на си, из /bin/bash (centos) + unixutils + остальная фигня упомянутая в .sh скриптах.

Вообще, подход autoexec.bat (sysvinit) не самый лучший в плане запуска современной системы.