Systemd 29

>А сразу запустить fsck.ext4 с нужными опциями он не может?

Это называется модульность.

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

Это ты, наверное, про скрипты и SysVinit.

>Если эти устройства нужны для запуска, то кто же будет за ними следить?

А вот и не нужны. А то с чего бы ему запрещать /usr отдельным разделом :)

Он в достаточной степени модулен. В чем разница между внешней программой и модулем, непонятно.

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

> systemd запускает systemd-fsck. systemd-fsck запускает fsck.ext4. Все 3 файла - бинарники.

SysVinit запускает скрипт. Скрипт порождает кучу процессов, лагает, запускает fsck. fsck запускает fsck.ext4. 3 бинарника и 1 скрипт.

Не так.

SysVinit запускает скрипт. Скрипт, не порождая ни одного процесса (возможности баша, поди, побольше, чем у systemd) запускает fsck, который запускает fsck.ext4. Итого: init, скрипт и ДВА бинарника.

systemd читает свой конфиг/скрипт. Затем запускает systemd-fsck, который запускает fsck (таки да, именно fsck), который запускает fsck.ext4. Итого: init, скрипт, и ТРИ бинарника.

И какой из этих вариантов лучше? В systemd не нужны лишние сущности.

Таки какой там вариант лучше? И где сущностей больше?

А какой из них более управляемый? SysVinit запускает скрипт. Скрипт лагает, мы открываем скрипт, видим причину лага и исправляем ее. systemd запускает бинарник, бинарник лагает. Мы в растерянности разводим руками и в сердцах вспоминаем винду.

>Это называется модульность.

Хоть как называй. Сути не меняет.

Это ты, наверное, про скрипты и SysVinit.

Скрипты уже лет 20 не были проблемой. Леннарт съел твой мозг?

>Итого: init, скрипт и ДВА бинарника.

Это и есть 3 бинарника и скрипт. Хотя даже 4, потому что init, bash, fsck, fsck.ext4.

таки да, именно fsck

Пруф? systemd, systemd-fsck, [fsck], fsck.ext4 - это 3-4 бинарника. А с SysVinit 4 бинарника и скрипт.

бинарник лагает

Бинарник не лагает. Никогда не было с ним ни одного бага на моей памяти.

> Он в достаточной степени модулен. В чем разница между внешней программой и модулем, непонятно.

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

И systemd ДИКО модульный. Настолько, что становится невозможно отследить, кто откуда запускается и кто что делает. Как мне, чорт побери, узнать, наконец, кто создает /var/lock/subsys? Этот вопрос вылез в первые десять минут ковыряния Fedora Rawhide с новым systemd. И даже на этот простой вопрос никто не может дать ответ.

>> таки да, именно fsck

Пруф?

Открой исходник и посмотри. :)

systemd, systemd-fsck, [fsck], fsck.ext4 - это 3-4 бинарника. А с SysVinit 4 бинарника и скрипт.

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

Так что в обоих твоих случаях - 4 бинарника и скрипт.

Какие годные аноны пришли в тему, приятно послушать, не то, что некоторые регистранты-леннартофилы. Даешь 500-ый гет!

Все новое всегда непонятно.

>Не забудь про systemd-скрипт, тот, что называется конфигом. Он ничем не лучше bash-скрипта.

конфиг не исполняется.

Наоборот, он на порядок хуже по возможностям.

откажись от рпм. Пусть будут кошерные инсталлеры. Максимум возможностей.

> Бинарник не лагает. Никогда не было с ним ни одного бага на моей памяти.

http://web.archiveorange.com/archive/v/w2t6lqdSJWnxqZKki7kr
https://bugzilla.redhat.com/show_bug.cgi?id=679492
http://lists.freedesktop.org/archives/systemd-devel/2011-May/002396.html

Это - проблемы, которых не было раньше, и которые появились с приходом systemd. И это на копеечном systemd-fsck. Бинарник не лагает, он не тормоз, он - медленный газ.

> Так что в обоих твоих случаях - 4 бинарника и скрипт.

Скорость вызова fsck вообще не важна. Написано же - основные расходы на создание процессов вызываются мелкими вещами вроде grep и cut.

А зачем она нужна? Я просто закрываю крышку макбука, еду на работу, открываю и у меня все работает.

>А какой из них более управляемый?

это можно понять только из практики.

SysVinit запускает скрипт. Скрипт лагает, мы открываем скрипт, видим причину лага и исправляем ее.

в какой-то момент скрипты начинают лагать только потому, что они скрипты.

systemd запускает бинарник, бинарник лагает. Мы в растерянности разводим руками и в сердцах вспоминаем винду.

Исходные коды бинарника отсуствуют? Все тоже самое. Смотрим исходники и лечим.

> Исходные коды бинарника отсуствуют? Все тоже самое. Смотрим исходники и лечим.

В системе собранной из RPM-бинарников, не поверишь, ВНЕЗАПНО отсутствуют. Т.е. надо ставить дебагинфо пакет, скачивать SRPM, ставить компилятор и отладчик на ПРОДАКШОН машине, которых там вообще не должно быть и отлаживать systemd. Понятное дело, Леннарт --- бохъ!

P.S. Я другой анонимус.

>Это - проблемы, которых не было раньше, и которые появились с приходом systemd.

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

> конфиг не исполняется.

Он парсится. Точно так же как и скрипт на баше.

Кстати, в случае systemd у тебя всегда 3 НОВЫХ бинарника: (конфиг), systemd-fsck, fsck, fsck.ext4. А в случае sysvinit у тебя 2 бинарника: (скрипт), fsck, fsck.ext4. Потому что bash остался с предыдущего раза, это - тот же самый баш, что выполнял сценарий rcS, из которого это все запустилось.

Я догадываюсь, откуда взялся этот костыль. Все было так: 1. Леннарт решил отказаться от запуска баш-скриптов 2. Он начал писать конфиги, и обнаружил, что его конфиги по сравнению со скриптами баша убоги чуть более чем полностью, и написать вменяемый конфиг для fsck не выходит. 3. Тогда он придумал костыль. Вместо скрипта он написал бинарник, который делает то же самое, что делал баш, но без баша. 4. После чего он заявил, что это не костыль, а такая фича. 5. ... 6. PROFIT?

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

> Скорость вызова fsck вообще не важна. Написано же - основные расходы на создание процессов вызываются мелкими вещами вроде grep и cut.

Да, наверняка. Из этого следует что? Правильно, надо всего лишь переписать несколько скриптов, убрав оттуда grep и cut. Возможности bash-а это позволяют.

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

>В системе собранной из RPM-бинарников, не поверишь, ВНЕЗАПНО отсутствуют.

Ога, и *.py тоже отсутствуют. Достаточно *.pyc или *.pyo.

только исходники всегда доступны.

Т.е. надо ставить дебагинфо пакет, скачивать SRPM, ставить компилятор и отладчик на ПРОДАКШОН машине, которых там вообще не должно быть

К любой продакшен машине должна быть дебаг машина. Раз уж вы такие правильные.

и отлаживать systemd. Понятное дело, Леннарт --- бохъ!

rpm же отладили. И systemd тоже отладят. И не будет таких эпичных багов в десятках повторяющихся скриптов.

>в какой-то момент скрипты начинают лагать только потому, что они скрипты.
В случае с init скорость ограничена I/O, поэтому пофиг.

> И на моём нетбуке он грузил за 30 секунд, что недопустимо.

O_o

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

>Он парсится. Точно так же как и скрипт на баше.

Скрипт, это скрипт. Это программа. Со всеми вытекающими.

Леннарт решил отказаться от запуска баш-скриптов

Имхо не так важно.

. Он начал писать конфиги, и обнаружил, что его конфиги по сравнению со скриптами баша

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

Алгоритм был повторен для каждого сервиса,

не так. Для каждой задачи. Все сервисы укладываются в одну задачу. fsck никогда не был сервисом.

> это мелкие нестыковки, которые были и будут всегда при смене одной программы на другую.

ДА! Чорт, побери, ИМЕННО!!!!

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

Печально, конечно, но это не повод отказываться от прогресса.

А где прогресс? Регресс налицо - проблемы, которые были исправлены 20 лет назад, вылезли снова. А где прогресс-то? Что ценного принес с собой systemd? Что там у нас с решенными задачами?

Изменение ради изменения - это не прогресс. Давайте перепишем GNOME/KDE/XFCE/... (любимый вариант подчеркнуть) на lisp-е? Зачем? Ну это же прогресс! Оно будет глючить, и поначалу не будет работать, но это - мелкие нестыковки, они всегда бывают. А через год мы бросим писать на лиспе и начнем писать все с нуля на хаскеле, опять вылелезут нестыковки, но что поделаешь, прогресс. А еще через год мы бросим хаскель и начнем писать на brainfuck...

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

>> Скорость вызова fsck вообще не важна. Написано же - основные расходы на создание процессов вызываются мелкими вещами вроде grep и cut.

Да, наверняка. Из этого следует что? Правильно, надо всего лишь переписать несколько скриптов, убрав оттуда grep и cut. Возможности bash-а это позволяют.

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

Но леннарт не был бы леннартом, если бы не взялся переписать все нафиг

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

> Да, он велосипедостроитель.

Он неплохой кодер, он пишет много и быстро, хотя обычно и с ошибками. Но как архитектора мне порой хочется его утопить.

Но важно понимать - его стратегия тоже может привести к работающему продукту.

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

Конечно, это будет стоить пользователям Федоры дополнительных нервов - но они знали, на что подписывались.

systemd уже есть во всех дистрибутивах кроме, наверное, дебиана. Так что это уже сейчас стоит нервов всем.

Но проблема даже не в этом. Если бы дело было в хорошей новой идее и плохой реализации, можно было бы, грубо говоря, взять двух (трех? четырех?) анонимусов и несколько регистрантов из этого треда и написать хорошую реализацию этой идеи. Но у systemd нет новой идеи. Это тот же upstart, только жирный, с глюками т.к. написан с нуля, с кучей костылей, и ни с кем не совместимый.

Я подозреваю, что он и работает медленнее, чем upstart. Хотел, вот, проверить, даже стянул себе fedora rawhide с последним systemd, но не могу найти, где эта скотина создает /var/lock/subsys.

> но не могу найти, где эта скотина создает /var/lock/subsys.

нашел. /usr/lib/tmpfiles.d/legacy.conf ... <незензурная речь>

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

У леннарта мозг рака. Товарищи эмигранты, наймите, пожалуйства, какого-нибудь негроафриканца, пусть он пристрелит леннарта! Я даже готов пожертвовать на это Б-гоугодное дело долларов триста-четыреста.

А можно ещё кого-нибудь?

Расстрельный список: почти все лидеры этих проектов.

>systemd уже есть во всех дистрибутивах кроме, наверное, дебиана.

Есть в тестинге, но несколько старый и по дефолту не используется.

(голосом Горби) хлавное — нАчать!

> Расстрельный список: почти все лидеры этих проектов.

Большая часть проектов там вполне годная.

> С systemd все стало просто и понятно...

И это только начало. У systemd есть свои mount-ы. Теперь, чтобы понять, что куда смонтировано, недостаточно посмотреть в /etc/fstab, надо еще и перечитать все его юниты. И это тоже не гарантирует понимание, потому что не все из них загружаются, и нет возможности определить, какой из них сработал/сработает, а какой - нет.

> Я подозреваю, что он и работает медленнее, чем upstart. Хотел, вот, проверить

Предварительная проверка на виртуальной машине показала, что по скорости запуска systemd в дефолтной конфигурации сливает upstart-у в дефолтной конфигурации примерно процентов на 10-15%.

PS: спасибо топикстартеру за новость, без нее я бы не взялся тестировать сабж на скорость

на F#? Ещё и модно будет :)

>>Всё это даёт возможность загружать систему за время порядка 10 секунд и выключать за 1 секунду.

Это какой-то сферический в вакууме сервер занимающийся ничем, следует полагать?

OpenRC тоже «грузит __любую__ систему» за 10 секунд! (за 10 секунд за щёт параллельности запуска сервисов появится окно входа в Х и ещё очень долго будет шуршать винт догружая остальные сервисы и долго приходится ждать приглашения входа в консоль... ;) )

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

проблема - тонны говн в инит-скриптах и отсутствие слежения за запущенным. Если посмотришь в инит скрипты, то увидишь как одна и
та же задача - запуск какого-нибудь демона решается десятью тысячами
разных костыльных способов. Где-то сподобились юзать start-stop-daemon,
где-то демоны сами запускаются, где-то вообще через screen, где-то
твориться полный аллес вообще.

Я уже не говорю про слежение за запуском... кто-то пид файлы создаёт, кто-то мониторящий процесс пускает, причём где-то пиды создаются демоном, где-то костылями, где-то вообще никакого контроля. Половина скриптов даже не скажет ничего умного, если демон подох. В gentoo даже есть спец. костыль под название 'zap', потому как stop может и не сработать.

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

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

Так что разбирать эту помойку и сделать наконец нормально давно пора.
Иначе так бы и сидели с /etc/rc.d и десятью тысячей симлинков.
Естественно, будут тонны кирпичей со всех сторон, но делать надо.

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

> Поэтому иксы не будут ждать инициализации сети

ай-ай-ай.

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

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

>возможность загружать систему за время порядка 10 секунд и выключать за 1 секунду.

и зачем это все? помнится мне, начал я пользоваться линуксом в 98 году, в то время на рабочем месте у меня был пентиум 200 и никак я не страдал от «медленного» sysv init...

>проблема - тонны говн в инит-скриптах и отсутствие слежения за запущенным.

ps -A | grep / pidof уже отменили? А уж про говно не к месту сказану. Бинарник, стартующий другой бинарник явно не лучше.

>2) описание сервисов. В системд сервис, это конфиг, а не скрипт. На мой взгляд, это сранимо с введением менеджера пакетов вместо инсталляторов.

Ошибочка. В systemd это не конфиг, а целая программа на сях. Да и ещё с ограничениями на возможности конфигурирования.

http://cgit.freedesktop.org/systemd/tree/src/kmsg-syslogd.c?id=f9a61ef2c9e3b3...

Явно посложнее будет самодостаточного скрипта.

Ждем ебилдов???

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

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

>Это - проблемы, которых не было раньше, и которые появились с приходом systemd.

Это проблемы не в systemd.

http://web.archiveorange.com/archive/v/w2t6lqdSJWnxqZKki7kr

Это баг в initramfs из SUSE. systemd помог его исправить.

https://bugzilla.redhat.com/show_bug.cgi?id=679492

Прогрессбар не нужен. Всё равно рано или поздно закончится.

http://lists.freedesktop.org/archives/systemd-devel/2011-May/002396.html

Тут у юзера кривой fstab.

>Ждем ебилдов???

Да в дереве уже давно.

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

Startup finished in 2710ms (kernel) + 14430ms (initrd) + 42785ms (userspace) = 59926ms

Ну а далее начнём с потребительской точки зрения.

При старте совершенно неинформативный срач. Про форматирование авторы забыли.

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

Делаем systemctl stop sshd.service

и видим

systemctl --failed UNIT LOAD ACTIVE SUB JOB DESCRIPTION pptp.service loaded ESC[1;31mfailed failedESC[0m LSB: This startup script launches pptp-command. shorewall.service loaded ESC[1;31mfailed failedESC[0m LSB: shorewall-common sshd.service loaded ESC[1;31mfailed failedESC[0m LSB: OpenSSH server daemon systemd-...-clean.service loaded ESC[1;31mfailed failedESC[0m Cleanup of Temporary Directories systemd-...-setup.service loaded ESC[1;31mfailed failedESC[0m Recreate Volatile Files and Directories systemd-...nlevel.service loaded ESC[1;31mfailed failedESC[0m Notify Audit System and Update UTMP about System Runlevel Changes

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

systemadm - совершенно убогая тулза, не умеющая даже сортировать и выводить в виде дерева с зависимостями.

Вот ещё феерия:

systemctl status sshd.service sshd.service - LSB: OpenSSH server daemon Loaded: loaded (/etc/rc.d/init.d/sshd) Active: failed since Mon, 20 Jun 2011 12:02:34 +0400; 7min ago Process: 7984 ExecStop=/etc/rc.d/init.d/sshd stop (code=exited, status=0/SUCCESS) Process: 7966 ExecStart=/etc/rc.d/init.d/sshd start (code=exited, status=0/SUCCESS) Main PID: 7974 (code=exited, status=255) CGroup: name=systemd:/system/sshd.service

Опять failed, хотя я штатно ручками его остановил.

Кроме того, при чём тут скрипт sshd непонятно. Получается, временный костыль, а иначе придётся писать программу на сях. Так?

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


Startup finished in 2710ms (kernel) + 14430ms (initrd) + 42785ms (userspace) = 59926ms

Ну а далее начнём с потребительской точки зрения.


При старте совершенно неинформативный срач. Про форматирование авторы забыли.


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


Делаем systemctl stop sshd.service

и видим

systemctl --failed
UNIT LOAD ACTIVE SUB JOB DESCRIPTION
pptp.service loaded ESC[1;31mfailed failedESC[0m LSB: This startup script launches pptp-command.
shorewall.service loaded ESC[1;31mfailed failedESC[0m LSB: shorewall-common
[b]sshd.service[/b] loaded ESC[1;31mfailed failedESC[0m LSB: OpenSSH server daemon
systemd-...-clean.service loaded ESC[1;31mfailed failedESC[0m Cleanup of Temporary Directories
systemd-...-setup.service loaded ESC[1;31mfailed failedESC[0m Recreate Volatile Files and Directories
systemd-...nlevel.service loaded ESC[1;31mfailed failedESC[0m Notify Audit System and Update UTMP about System Runlevel Changes


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


systemadm - совершенно убогая тулза, не умеющая даже сортировать и выводить в виде дерева с зависимостями.


Вот ещё феерия:

systemctl status sshd.service
sshd.service - LSB: OpenSSH server daemon
Loaded: loaded (/etc/rc.d/init.d/sshd)
Active: failed since Mon, 20 Jun 2011 12:02:34 +0400; 7min ago
Process: 7984 ExecStop=/etc/rc.d/init.d/sshd stop (code=exited, status=0/SUCCESS)
Process: 7966 ExecStart=/etc/rc.d/init.d/sshd start (code=exited, status=0/SUCCESS)
Main PID: 7974 (code=exited, status=255)
CGroup: name=systemd:/system/sshd.service


Опять failed, хотя я штатно ручками его остановил.


Кроме того, при чём тут скрипт sshd непонятно. Получается, временный костыль, а иначе придётся писать программу на сях. Так?


ЗЫЖ первое можно грохнуть из-за форматирования

Читаю топик. Горд за анонимусов. Они хорошие, годные.

Кто нибудь их слакофилов пробовал это водрузить?

>14430ms (initrd)

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

systemctl --failed почему-то выводит через more.

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

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

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

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

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

Кроме того, при чём тут скрипт sshd непонятно.

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

первое можно грохнуть из-за форматирования

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