Собака лает — ветер носит.

> Регресс налицо - проблемы, которые были исправлены 20 лет назад, вылезли снова. А где прогресс-то?

Гм, на системе какого года выпуска вы работаете? Надо полагать, 1991?

Прогресс - это достижение новых, недостижимых ранее целей. А это, это не прогресс, это маразм, создание видимости работы. Мы делаем вид, что мы что-то делаем, и весь мир ДОЛЖЕН нам помогать. А потом мы придумаем что-нибудь новое.

Не понимаю — это вы от своего имени говорите или спекулируете от имени авторов systemd?

Я чайник, имя «Леннарт» слышу впервые, но с моей колокольни всё видится так:

1. Гн. Леннарт СДЕЛАЛ что-то, и имел достаточно возможностей и способнойстей ПРОПИХНУТЬ это как минимум в Федору.

2. Вы же ГОВОРИТЕ что гн. Леннарт сделал херню, которую не надо было делать.

Имхо, вы не в том положении, чтобы указывать Леннарту что и как делать... Вот если бы вы 20 лет назад основали РедХат или что-то подобное, а потом няняли Леннарта на работу, то сейчас бы говорили ему что и как делать. Но, поскольку вы такую возможность упустили, остаётся только трындеть на ЛОРе. Что ж, собака лает — ветер носит...

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

Ну так и не меняйте. Работайте на системе, выпущенной 20 лет назад.

Чао. Совсем другой анонимус.

Затестил, прибавлений скорости не заметил. Вообще.

А что ты хочешь, если твой systemd попрежнему стартует те же самые init скрипты? Установи service файлы и будет быстрее.

Вообще все обсуждение о скорости немного не в то русло идет. Скорость это побочный эффект, а не основная цель systemd.

> проблема - тонны говн в инит-скриптах

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

Так что разбирать эту помойку и сделать наконец нормально давно пора.

Никто ж не спорит, конечно, неплохо бы вместо помойки использовать общий стандартизованный механизм. Но причем тут systemd? Помойка в нем еще хуже, чем помойка в init-е, там она хоть на баше была, ее можно было ковырять без глубокого знания программирования, а в systemd помойка с бинарниками, и эту помойку хрен прочистишь.

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

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

Даже переписывать не надо - сделать встроенные grep, cut и прочие (баш это позволяет).

Это всё есть в Perl ;) Но, даже это, я думаю, ерунда.

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

А вот это, скорее всего, реальный профит.

Запуск grep, sed, cut & co тормозит только в первый раз, когда они читаются с диска и связываются с библиотеками, после чего они в кеше и запускаются мгновенно. Переписать скрипты на Perl, Tcl или что-то подобное решилобы даже эти мелкие проблемы. Реальный профит скорости загрузки в правильном распараллеливании. IMHO.

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

А вот это, скорее всего, реальный профит.

Только есть одно но: SysVinit сможет максимум сделать зависимости между демонами, а systemd позволяет сделать зависимости от устройств, точек монтирования, таймеров, данных в сокетах и многого другого.

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

avahi? AFAIK, альтернативы ему вообще нет

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

> Вот нифига. Это если второй скрипт соурсить точкой или командой 'source'. Но тогда ему нельзя передать параметр start. Поэтому вызывается новый скрипт и новый интерпретатор.

Парсится новый скрипт, а нового интерпретатора нет, делается форк старого. Никакие новые бинарники с диска не читаются, никакие библиотеки не подгружаются.

>когда avahi не работает - этого обычно никто не видит.

А что вообще этот avahi делает? По мне, что установлен, что нет - разницы не вижу. Кстати, так должно быть и с systemd.

>> Даже переписывать не надо - сделать встроенные grep, cut и прочие (баш это позволяет).

Это всё есть в Perl ;)

Так это переписывать надо было бы.

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

А вот это, скорее всего, реальный профит.

Наверное. Обидно, что первый раз (известный мне) это было сделано почти 10 лет назад, причем в нормальном юниксвейном стиле: http://www.linuxsymposium.org/archives/OLS/Reprints-2002/gooch-reprint.pdf

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

>а нового интерпретатора нет, делается форк старого

Поделил на ноль. Форк старого и будет новым интерпретатором.

> Должен через less. И то, что он выводит через less - был баг.

«Это не баг, это фича», серьезно: https://bugzilla.redhat.com/show_bug.cgi?id=713567 «Исправлять мы это не будем, ведь кому-то это может не понравиться...»

Отучить не представляется возможным.

--no-pager, очевидно же. :)

С какого перепугу он попал в failed, для меня остаётся загадкой.

У меня в dead числился сервис, который при этом висел в памяти...

>У меня в dead числился сервис, который при этом висел в памяти...

Это мог быть зомби.

>А что вообще этот avahi делает?
Находит ябблокомпьютеры и себе подобных в локальной сети. Может дополнять NFS-шары (в SMB уже встроен аналогичный костыль)

> Поделил на ноль. Форк старого и будет новым интерпретатором.

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

> Только есть одно но: SysVinit сможет максимум сделать зависимости между демонами, а systemd позволяет сделать зависимости от устройств, точек монтирования, таймеров, данных в сокетах и многого другого.

А mysql позволяет делать вложенные запросы между несколькими таблицами, а systemd не позволяет. Давайте использовать mysql в качестве init-демона? Нет? Почему? Потому что запросы к базе данных не имеют отношения к загрузке системы? А какое отношение к загрузке системы имеют таймеры, устройства и сокеты?

Лишние фичи в init-е не помогают, а мешают, тормозят работу и усложняют интерфейс. Если в systemd дописать тетрис, и заставить при запуска отображать фотографии мисс-вселенной 2010, это ни на каплю не прибавит ему ценность, как init-демону.

>Находит ябблокомпьютеры и себе подобных в локальной сети.

Мой iPod не нашло. Себя самого нашло, дало смонтировать sftp. sshd и mDNSResponder на iPod запущены. Что-то не очень это Avahi работает.

// И да, заодно увидел, что у меня зомби на яблозонде висит с pid=2 под именем bash.

>Это не винда, форк в юниксе - это легкая операция, намного легче подгрузки нового бинарника и его линковки с пачкой библиотек.

Спасибо, капитан обвиус.

> А что вообще этот avahi делает? По мне, что установлен, что нет - разницы не вижу. Кстати, так должно быть и с systemd.

http://ru.wikipedia.org/wiki/Avahi

если у тебя в сети нет никаких сервисов Zeroconf, то как работает avahi ты не увидишь

>А какое отношение к загрузке системы имеют таймеры, устройства и сокеты?

Прямое. Появился девайс винта - fsck - смонтировать. Сразу. А без этого будет: появились все разделы винта - все по очереди fsck - потом все по очереди смонтировать. Когда монтировать первый проверенный можно было, пока проверяется второй. Или же можно не запускать лишние демоны (sshd или avahi, например), пока по сокету не пришли данные. Когда они стали нужны - запустятся.

Если в systemd дописать тетрис, и заставить при запуска отображать фотографии мисс-вселенной 2010

Тетрисом занимается TuxOnIce, а фотографии мисс-вселенной показывает plymouth, очевидно же.

> Появился девайс винта - fsck - смонтировать. Сразу.

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

Тетрисом занимается TuxOnIce, а фотографии мисс-вселенной показывает plymouth, очевидно же.

Таки да! А данными в сокетах xinetd, а запуском по времени cron. И в init-е этому не место.

PS: Тетрисом занимается TuxOnIce? 0_o

Athlon 1700+.

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

>На этапе загрузки это не нужно. Когда init-демон запускается - все разделы уже есть, иначе ему неоткуда было бы запускаться.

Не все. Рутовый есть, другие - не точно. Если там флеш какая-нибудь тормозная. Или bluetooth. Когда он будет воткнут, запустится bluetoothd, когда вынут - выключится демон. Или любое другое устройство.

а запуском по времени cron.

Это не то. Тут, как at, а не cron. И зачем кучка демонов, которые ещё и запускать надо, если есть один универсальный?

Тетрисом занимается TuxOnIce? 0_o

Когда-то давно где-то это видел в списке фич TuxOnIce. Сейчас не нашёл уже.

> Если там флеш какая-нибудь тормозная.

Какая разница? Если ее нет в fstab-е, то она не тормозит загрузку. А если есть, то она ОБЯЗАНА тормозить загрузку всех сервисов, зависящих от local_fs. Для случая, чтобы она числилась в fstab-е, не тормозила загрузку, и монтировалась тогда, когда появится - придуманы autofs/hal/udisks.

Или bluetooth. Когда он будет воткнут, запустится bluetoothd, когда вынут - выключится демон.

Никто не мешает вписать его в правила udev-а и запускать bluetoothd при появлении устройства. Это опять-таки работа udev, а не init-демона.

Это не то. Тут, как at, а не cron.

Кстати, имхо, неплохо бы написать демон, который совмещает функции cron, anacron и atd - они почти полностью дублируют друг друга. Логично иметь в памяти один демон вместо трех одинаковых. Или это уже сделано?

Одинаковые задачи можно решать в одной программе. Разные задачи должны решаться в разных программах. Особенно, когда уже есть программы, хорошо решающие эти задачи. Это - базовые принципы UNIX.

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

Зачем останавливаться на небольшой кучке демонов? Совместим их все в один. Надо написать демон, который совмещает функции httpd, cups и gdm. Зачем кучка демонов, когда можно написать один универсальный? Тогда все будет зашибись - стартует ядро и запускает один единственный демон, который делает ВСЁ, и называется win...

PS: Так вот почему bluetooth в F15 не пашет. Оказывается ее должен был стартовать systemd при появлении bluetooth-адаптера... Только что-то не стартует он.

> Этого не достаточно, нужно еще и в package.unmask править.

package.keywords достаточно, если написать просто 'sys-apps/systemd', а не 'sys-apps/systemd ~x86'. У меня так, работает.

В случае захардмасканного пакета этого не достаточно. А на x86_64 он захардмаскан.

Но OpenRC - тот ещё тормоз, с systemd я просто рад и счастлив 12-секундной загрузке и 1-секундному выключению.

У меня и так время загрузки относительно мало.

>А если есть, то она ОБЯЗАНА тормозить загрузку всех сервисов, зависящих от local_fs.

Нет. Она обязана тормозить только то, что именно от неё зависит. Тогда получается профит в скорости.

Никто не мешает вписать его в правила udev-а и запускать bluetoothd при появлении устройства. Это опять-таки работа udev, а не init-демона.

Ога, напишем для каждого устройства по правилу udev. И для usb-принтера udev почему-то cups не запускает, а в systemd это делается гораздо проще.

Кстати, имхо, неплохо бы написать демон, который совмещает функции cron, anacron и atd - они почти полностью дублируют друг друга.

Есть fcron, который является совмещённым cron и anacron по функциональности. В LFS он дефолтный

Надо написать демон, который совмещает функции httpd, cups и gdm. Зачем кучка демонов, когда можно написать один универсальный?

Это совсем другое. Тут systemd разруливает общую задачу - запуск сервисов при наступлении самых разнообразных условий. А раньше было по демону на каждое условие.

Одинаковые задачи можно решать в одной программе. Разные задачи должны решаться в разных программах. Особенно, когда уже есть программы, хорошо решающие эти задачи. Это - базовые принципы UNIX.

Тут как раз задача одна - запуска сервисов по многим условиям. А если надо, чтобы зависело от устройства и активировалось по сокету - как это сделать без systemd, с помощью udev и xinetd?

PS: Так вот почему bluetooth в F15 не пашет. Оказывается ее должен был стартовать systemd при появлении bluetooth-адаптера... Только что-то не стартует он.

Gentoo, УМВР. А bluetooth не пашет, скорее всего, потому же. почему и мой WiFi в Fedora - ядро не содержит нужных модулей.

>А на x86_64 он захардмаскан.

А, ну я ж не знал, у меня x86_32.

У меня и так время загрузки относительно мало.

А вот у меня ускорилось более, чем в 2 раза. С OpenRC было 30 секунд. Даже арчевский SysVinit с его недоbsdшными скриптами был быстрее OpenRC.

>Много. Что там такого в том initrd?

Не важно.

Должен через less. И то, что он выводит через less - был баг.

Его исправили перед тем как в дистры пихать? Вижу, что нет.

Сорцы в руки :)

Подчищать тупняк за оплачиваемым специалистом? Нет уж.

Потому что демон sshd завершился с ненулевым кодом.

Почему? Где это исправить?

Какой скрипт?

Для поднятия ssh.

Лучше бы залогинился, сам бы удалил. И выхлопы systemctl лучше бы в [code][/code] обернул, читать же невозможно.

Но к делу это отношения не имеет. Не та ли?

>А что ты хочешь, если твой systemd попрежнему стартует те же самые init скрипты? Установи service файлы и будет быстрее.

Установить? Или написать сишную обёртку? А то я что-то не вкурил.

Вообще все обсуждение о скорости немного не в то русло идет. Скорость это побочный эффект, а не основная цель systemd.

Ну так вроде все кричат именно про скорость. А иначе трудно объяснить использование c вместо скриптов.

>Его исправили перед тем как в дистры пихать? Вижу, что нет.

Его не будут исправлять, т.к. есть ключ --no-pager.

Почему? Где это исправить?

В демоне sshd.

Для поднятия ssh.

В systemd нет скрипта для поднятия ssh.

>Установить?

Установи service файлы

По-русски, кажется. Их можно включать 'systemctl enable нужный_юнит'. Например, 'systemctl enable sshd.service' или 'systemctl enable sshd.socket' для активации по сокету. А старые init-скрипты надо выпилить из запуска, чтобы systemd их не трогал.

И да, вот тут везде анонимусы кричат, что с systemd куча проблем, а с SysVinit их не меньше. Вот уже тред, где не выключается: http://www.linux.org.ru/forum/desktop/6405260?lastmod=1308569153861

Вот когда будут готовые юниты под все демоны и сервисы, вот тогда можно будет пробовать этот ваш systemd. А до тех пор пока нужно будет создавать геморой в виде

File: /etc/systemd/system/network.service

[Unit]
Description=Network Connectivity
Before=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/ifconfig eth0 192.168.1.2 mtu 1496
ExecStart=/sbin/route add default gw 192.168.1.1
ExecStop=/sbin/ifconfig eth0 down

[Install]
WantedBy=multi-user.target

ЗЫ: правильно настроенный openrc работает не медленней этого вашего systemd, а приемущества в виде сокетов, устр-в и прочего решаються с помощью сторонних утилит (unix-way же ж), например, udev и его правила.

>Его не будут исправлять, т.к. есть ключ --no-pager.

Ты же сам сказал, что баг. Выходит, врал? И почему другие программы выводят нормально без этого less?

В демоне sshd.

Что в нём исправлять? Ссылка на багрепорт есть? А то вот, кроме как в systemd этот баг ни где не проявляется.

В systemd нет скрипта для поднятия ssh.

О чём и вопрос. Мне его на си обязательно переписать? Почему этого не сделал разработчик?

pptp тоже показывает failed. Выходит, в нём тоже баг?

>Вот уже тред, где не выключается:

А ты уверен, что это именно из-за SysVinit?

>Ты же сам сказал, что баг. Выходит, врал?

Я имел в виду, что он на багтрекере есть. Его решили не исправлять, потому что есть опция --no-pager.

Что в нём исправлять? Ссылка на багрепорт есть? А то вот, кроме как в systemd этот баг ни где не проявляется.

Может, sshd всегда по SIGTERM выходит с кодом 255, но скрипты, используемые в SysVinit, делали вид, что он завершился нормально (костыль в скриптах SysVinit). Поэтому и не исправляли.

О чём и вопрос. Мне его на си обязательно переписать? Почему этого не сделал разработчик?

Потому что «скрипт для поднятия ssh» в systemd не нужен. Он там поднимается без скриптом двумя способами: как демон - 'systemctl enable sshd.service' и с активацией по сокету - 'systemctl enable sshd.socket'.

>А ты уверен, что это именно из-за SysVinit?

Там Дебиан. В Дебиане SysVinit.

>pptp тоже показывает failed. Выходит, в нём тоже баг?

С pptp не знаю, т.к. лично не проверял. sshd проверил - выходит с кодом 255 при получении SIGTERM.

>Я имел в виду, что он на багтрекере есть. Его решили не исправлять, потому что есть опция --no-pager.

Весьма странное решение.

Может, sshd всегда по SIGTERM выходит с кодом 255, но скрипты, используемые в SysVinit, делали вид, что он завершился нормально (костыль в скриптах SysVinit). Поэтому и не исправляли.

Так может или точно? А то вот, смотрю /usr тоже нельзя отдельным разделом. Якобы из-за кривого mysql, кажется. Непонятно, откуда столько багов взялось?

Потому что «скрипт для поднятия ssh» в systemd не нужен. Он там поднимается без скриптом двумя способами: как демон - 'systemctl enable sshd.service' и с активацией по сокету - 'systemctl enable sshd.socket'.

А его как поднимал по-твоему? Той же самое командной, которая, как выяснилось зачем-то дёргает скрипт sshd. Зачем? И как сделать нормально?

>Может, sshd всегда по SIGTERM выходит с кодом 255, но скрипты, используемые в SysVinit, делали вид, что он завершился нормально (костыль в скриптах SysVinit).

Почитал скрипты из Генты и Арча по поводу запуска sshd. Там он запускается в фоне, поэтому при остановке через start-stop-daemon или kill мы не можем получить код завершения sshd. Тогда скрипты говорят «OK», потому что успешно убился процесс. Именно убился, а не завершился, т.е. код возврата kill (а не sshd) равен 0. systemd же говорит failed, потому что он видит, что sshd завершился с кодом 255, т.е. неуспешно.

Т.е. init-скрипты анализируют успешность убивания, а systemd - успешность завершения. systemd прав.

>С pptp не знаю, т.к. лично не проверял. sshd проверил - выходит с кодом 255 при получении SIGTERM.

Ну и когда всё это исправят? И, главное, кто? И почему всё раньше работало?

>Т.е. init-скрипты анализируют успешность убивания, а systemd - успешность завершения. systemd прав.

А почему ты так думаешь? Я вот иного мнения. Главное, прибить процесс. А уж как он там прибился, дело явно не init, а самого процесса.

>Там Дебиан. В Дебиане SysVinit.

И что? Зависнуть может только из init-a Так что ли?

>Главное, прибить процесс. А уж как он там прибился, дело явно не init, а самого процесса.

systemd прибил процесс. Он успешно справился с этой задачей. Но при этом дал _больше информации_, чем SysVinit: оказывается, процесс некорректно завершился. И если процесс _внезапно_ завершится (без команды stop), то systemd сразу об этом узнает, а SysVinit - не раньше команды status.

> И почему всё раньше работало?

Ну как же, раньше все было неправильно, и оно все устарело. А теперь все будет правильно.

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

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

>А его как поднимал по-твоему? Той же самое командной, которая, как выяснилось зачем-то дёргает скрипт sshd. Зачем? И как сделать нормально?

Какой к чёрту «скрипт sshd»? Что это вообще такое?

sshd поднимается одной командой:

systemctl enable sshd.service

Всё. Никакие скрипты не нужны. О чём ты вообще?

>Правда, раньше все работало, а теперь полезли проблемы, но мы не будем считать это проблемами, мы назовем это «прогрессом». Классная отмазка. Теперь каждый раз, когда какая-нибудь программа глючит или виснет, это можно списать на «прогресс». У нормальных людей прогресс - это решение новых задач, а у нас «прогресс» - это новые глюки.

Какие проблемы? Что, sshd не останавливается? Или потом не запускается? Всё работает, как надо.

А то, что в 'systemctl status sshd.service' будет failed - так это не баг, это фича systemd. Фича заключается в том, что systemd может анализировать код завершения демона (в отличие от SysVinit, который не может). А т.к. демон вышел с ненулевым кодом 255 - systemd сказал об этом пользователю. Всё правильно.

> И если процесс _внезапно_ завершится (без команды stop), то systemd сразу об этом узнает, а SysVinit - не раньше команды status.

И systemd и sysvinit «узнают» об этом одинаково. Но зато если я остановлю ssh, то sysvinit узнает и больше ничего не сделает, если процесс не числился в respawn. А systemd по всем правилам его перезапустит, а чо, он же «внезапно» завершился...

>С systemd все стало просто и понятно... Я даже в винде еще никогда не грепал всю файловую систему, чтобы найти один чертов файлик.

Ну и зачем всю систему грепать?

grep «/run/lock/subsys» `rpm -ql systemd`

/usr/lib/tmpfiles.d/legacy.conf:# systems. /run/lock/subsys is used for serializing SysV service

/usr/lib/tmpfiles.d/legacy.conf:d /run/lock/subsys 0755 root root -

И кстати, что дало сие сакральное знание?