судя по тексту новости оно делает и кучу фигни которая на десктопах может и нужна, но на серверах нет: фреймбуферы, сканеры, 3д принтеры

это initd?

Это udev.

У любого инструмента есть своя сфера применения.

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

Сгинь, нечистая.

так вот и нафига везде пихать systemd ?

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

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

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

Сейчас, одним пакетом systemd (не бинарником, а комплексом бинарников) можно охватить фактически весь системный уровень. От создания tty до настройки сети. Это банально удобно. Потому и используют.

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

Ещё вспомнился случай с изменяющимися названиями интерфейсов. Да-да, этих, которые, якобы, стабильные enp0s25.

Тебе ж еще три года назад пояснили, что systemd тут ни при чем.

Тебе ж еще три года назад пояснили, что systemd тут ни при чем.

Да мне по барабану, в общем-то. Кто udev разрабатывает ? Команда systemd. Точка. Ядро сменилось, «стабильные» буквы уехали. На сервере, между прочим.

Из свеженького:

Committing changes...
Preparing...                 ##################################### [100%]
1: syslog-ng                 warning: /etc/syslog-ng/syslog-ng.conf created as /etc/syslog-ng/syslog-ng.conf.rpmnew
##################################### [100%]
Job for syslog-ng.service failed because the control process exited with error code. See "systemctl status syslog-ng.service" and "journalctl -xe" for details.

● syslog-ng.service - LSB: Start syslog-ng daemon at boot time
   Loaded: loaded (/etc/rc.d/init.d/syslog-ng; bad; vendor preset: enabled)
   Active: failed (Result: exit-code) since Mon 2016-05-30 16:48:47 SAMT; 23s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 2799 ExecStop=/etc/rc.d/init.d/syslog-ng stop (code=exited, status=0/SUCCESS)
  Process: 2822 ExecStart=/etc/rc.d/init.d/syslog-ng start (code=exited, status=139)
    Tasks: 1 (limit: 512)
   CGroup: /system.slice/syslog-ng.service
           └─2830 /sbin/minilogd

такой ажиотаж вокруг системд конспект по нем написать, популярная вещь походу

Это настраивается в юните (SuccessExitCodes=, ЕМНИП). Если у вас в дистрибутиве мейнтейнеры не знакомы с поддерживаемым ими софтом — ну кто виноват?

Это настраивается в юните (SuccessExitCodes=, ЕМНИП).

Нет юнита, а в systemd заявлена поддержка init-скриптов. Увы и ах. Такая вот поддержка.

Кто udev разрабатывает ? Команда systemd. Точка.

Встречный вопрос — откуда такое именование сетевых интерфейсов по умолчанию в CentOS 6, в котором systemd нет и не предвидится, а версия udev — 147 (т. е. сильно предшествующая объединению)?

в котором systemd нет и не предвидится, а версия
udev — 147 (т. е. сильно предшествующая объединению)?

Вероятно, запатчили в RHEL те же люди. Кажется, udev в чистом виде так себя раньше не вёл. Или, может быть, там просто ещё не выкинули /lib/udev/rules.d/75-persistent-net-generator.rules тогда, а в CentOS выкинули.

Кстати, что вот тут Поттерингу не понравилось ?
http://github.com/systemd/systemd/issues/2642

В systemd заявлена поддержка LSB-совместимых инит-скриптов. Я более чем уверен, что по стандарту инит-скрипт не имеет права возвращать неноль.

Я более чем уверен, что по стандарту инит-скрипт не
имеет права возвращать неноль.

Я более, чем уверен, что, вне зависимости от LSB, никто не вмешивается в то, что запустил, или не запустил, init-скрипт.

И что с того? Bug-to-bug compatibility никто не обещал.

И что с того? Bug-to-bug compatibility никто не обещал.

Ну, то есть, давайте делать новые баги. Где тут написано, что нельзя не 0 ?

http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/ini...

Так же не написано, что если не 0, надо убить процесс.

Я более, чем уверен, что, вне зависимости от LSB, никто не вмешивается в то, что запустил, или не запустил, init-скрипт.

Могу точно сказать, что выполнение /etc/rc.local прерывается на первом-же не нулевом возврате. Молча. Заставляя гадать, что там предшественники накрутили.

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

Так же не написано, что если не 0, надо убить процесс.

Там написано, что если program is running or service is OK, то должен вернуться 0.

Если возникла ошибка - то процесс неработоспособен, соответственно надо убить его, и всех его потомков. Что собственно и сделано.

Такая логика имеет полное право на жизнь. Если скрипт вернул 1, надо убивать его, и его потомков? Или пусть мусор в системе висит и память зря жрёт?

Кажется, udev в чистом виде так себя раньше не вёл.

Вел и ведет. И не только в CentOS, но и в System Rescue CD, к примеру. И наличие /lib/udev/rules.d/75-persistent-net-generator.rules (в шестом CentOS он есть) этому не мешает.

Если возникла ошибка - то процесс неработоспособен

Ты это где прочитал ? И где ты прочитал, что не ноль - ошибка ?

Если скрипт вернул 1

Скрипт вернул не 1, как видно из «code=exited, status=139»

И наличие /lib/udev/rules.d/75-persistent-net-generator.rules (в шестом CentOS он есть) этому не мешает.

Даёт удобочитаемые, удобозапоминаемые и постоянные имена интерфейсов. Если это убрать, то получается лажа. А если убрать код, поддерживающий переименование, то получается, и вовсе, задница.

Могу точно сказать, что выполнение /etc/rc.local прерывается
на первом-же не нулевом возврате.

Я, даже, было поверил. Но нет:

May 30 23:50:45 root: -- 1 --: 1
May 30 23:50:45 root: -- 2 --: 1
May 30 23:50:45 root: -- 3 --: 1

/etc/rc.d/exit1
/usr/bin/logger -- "-- 1 --: "$?
/etc/rc.d/exit1
/usr/bin/logger -- "-- 2 --: "$?
/etc/rc.d/exit1
/usr/bin/logger -- "-- 3 --: "$?

Сказал - как в лужу пернул

Тут есть и нормальные, адекватные анонимусы, без системд головного мозга

139 — это -11, SIGSEGV. Оно упало.

Оно упало.

Тебе показалось. Оно работает при обновлении с sysvinit. Вероятно, есть проблема при обновлении какого-то плагина, но это не сказывается на итоге. Демон честно рапортует, что не всё в порядке, но это никак не повод его сшибать.

Я понятия не имею, что там происходит, т. к. не пользуюсь Debian, но если там написано 139 — значит, инитскрипт точно не вернул ноль. Насколько я помню, отрицательные коды возврата там обозначают прилетевшие сигналы.

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

Я, вроде, привёл ссылку на

In case of an error while processing any init-script action except for status, the init script shall print an error message and exit with a non-zero status code:

1 generic or unspecified error (current practice)
2 invalid or excess argument(s)
3 unimplemented feature (for example, «reload»)
4 user had insufficient privilege
5 program is not installed
6 program is not configured
7 program is not running
8-99 reserved for future LSB use
100-149 reserved for distribution use
150-199 reserved for application use
200-254 reserved

И нет, это не deb-based.

Скрипт вернул не 1, как видно из «code=exited, status=139»

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

И откуда systemd должен знать, при каком коде возврата
всё нормально, а при каком - всё пропало?

Не его дело решать. Вообще. Его дело запустить и не отсвечивать.

Не его дело решать. Вообще. Его дело запустить и не отсвечивать.

Ты, конечно, можешь считать, что неудачно стартовавшие демоны можно не чистить. Но я с тобой не согласен. Авторы systemd, видимо, тоже.

Имхо, тут обсуждать нечего.

Я, вроде, привёл ссылку на

Я говорил про systemd и его условные обозначения.

Ну и да, мне нечего добавить к последнему сообщению Ivan_qrt.

Ты, конечно, можешь считать, что неудачно стартовавшие демоны можно не чистить.

Не разработчикам systemd определять удачность старта демонов. Неудачно стартовавший демон завершает работу сам, без подсказок со стороны кривого init, который даже ФС нормально почекать не умеет.

Этим «разработчикам» пишут про remote syslog, а они закрывают фичереквест, как не баг, со ссылкой на какие-то формальные правила.

При всех проблемах systemd, но в этом споре на стороне «вернуль не 0 - значит всё упало». Если всё-таки другой exitcode не является ошибкой, а просто рапортует о какой-то некритичной проблеме, автор service-файла должен это указать через опцию SuccessExitStatus.

автор service-файла должен это указать через опцию SuccessExitStatus.

С этим я готов согласиться, но его нет. Есть init-скрипт, заявлено о поддержке и сломано поведение. Был бы юнит, был бы другой разговор.

Попробуй

echo "SuccessExitStatus=139" > /etc/systemd/system/syslog-ng.service.d/exit-status.conf

//понятно, почему ты 20 лет админ, и никакого роста

/etc/systemd/system/syslog-ng.service.d/

Юнита НЕТ ! Что там, в документации ? Это override что ?

и никакого роста

Тебе так кажется. :-)

Юнита НЕТ

Есть. Не гарантирую, что это сработает, но попробовать стоит.

Что там, в документации ? Это override что ?

Ну возьми да почитай.

Не гарантирую, что это сработает, но попробовать стоит.

Вопрос в поломке поведения. Тут уж лучше юнит сделать сразу.

Ну возьми да почитай.

Так написано, что параметры в юнитах переопределять. Про init не написано.

Тут уж лучше юнит сделать сразу.

Лучше.

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

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

Хм. Убунту 12,04 точно выполнение останавливалось.

Собственно вот: http://askubuntu.com/questions/239600/why-doesnt-rc-local-run-all-my-commands...
И костыли.
https://www.google.ru/search?q=rc.local continue on error

# cat /etc/rc.local

#!/bin/sh -e

rc.local запускается /bin/sh -e, а значит выполнение этого скрипта останавливается на первом не нулевом возврате.

# cat /etc/issue

Ubuntu 14.04.3 LTS \n \l

rc.local запускается /bin/sh -e

Кто такой этот /bin/sh в Убунту (/bin/sh --version) ? Что за ключ "-e" ? У меня такого нет. Если именно он это поведение определяет, то тот, кто его поставил, и хотел такое поведение.

# /bin/sh --version
/bin/sh: 0: Illegal option --

# stat /bin/sh 
  File: ‘/bin/sh’ -> ‘dash’
# man sh

           -e errexit       If not interactive, exit immediately if any untested command fails.  The exit status of a command is considered to be explic‐
                            itly tested if the command is used to control an if, elif, while, or until; or if the command is the left hand operand of an
                            “&&” or “||” operator.

Дефолт убунты 1404LTS. Думаю в дебиане так-же. А вот в центоси прикольней:

# stat /bin/sh
  File: «/bin/sh» -> «bash»
# cat /etc/issue
CentOS release 6.3 (Final)
# cat /etc/rc.local
#!/bin/sh

А вот в центоси прикольней:

Не прикольней, а так, как было всегда. dash - это достаточно недавнее веянее. :-)

Не прикольней, а так, как было всегда. dash - это достаточно недавнее веянее. :-)

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

Зато благородя этим мелочам у меня выработалась привычка ничего не писать в /etc/rc.local. Ибо оно является этаким autoexec.bat и лучше туда ничего не костылить.

На ноуте с SSD и без UEFI

А теперь на том же железе стартани Слаку. Ты удивишься, родной.

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

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

Я чуть динамики ноута не спалил из-за пзрррррщаудио. Оно само громкость как хочет, так и регулирует. Сустемд тоже живет своей необъяснимой жизнью.