Systemd 29

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

\\ разбросаность конфигов по етц связана с идеей не перемещать конфиги сервисов а брать их там где их клал автор демона.. фича сомнительная.. но меняется быстро

Похоже,мало им блобов в системе. Ну будет система грузиться не 20, а 10 секунд (походу, сферический в вакууме вариант). Между скоростью загрузки и возможностью контроля системы я выберу последнее. Кто, спрашивается, мешает любителям скоростей гибернацию пользовать.

Самый главный минус его дизайна: этот комбайн с 1001 функцией не нужен.

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

Анонимус выше уже описал:

возможность запуска сервисов по появлению данных в сокете

Не нужно в init-е, есть xinetd, это его работа.

наличию подключённых устройств или смонтированных файловых систем

Тоже не нужно в init-е. Есть udevd и udisks.

встроенное упреждающее чтение с диска

Внезапно, readahead.

интеграция с cgroups

Не нужно в init-е. Есть ulatencyd.

Идём дальше. Для обработки событий таймера есть cron и at. Что там еще? Интеграция с dbus — бесполезный костыль.

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

В результате получили эталонное Не Нужно. Блюдо готово можно подавать к столу.

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

Я уже писал выше, она не зависает, надо подождать около 3 минут. В арче кривой syslog-ng, если его убрать, то всё нормально. В Генте и с сислогом работает.

настройки эти у systemd разбросаны по всему /etc и парсеры из arch-systemd-units не все из /etc/rc.conf выбирают

Тут 2 варианта: или использовать нативные конфиги systemd, или /etc/rc.conf. Что по существу они не выбирают? Если это что-то типа «русская локаль в сообщениях» или «цветные сообщения», то это не нужно (systemd русский не умеет, а по дефолту и сообщения не печатает). Если это что-то действительно важное, то тут уже надо арчепарсер пилить.

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

Это по меньшей мере странно, потому что с инитом я не достигал тех скоростей, которые в systemd из коробки. Если установить systemd на свежеустановленную Генту, то грузится за 5 секунд (у меня) с несколькими демонами. Когда я писал свои init-скрипты для SysVinit, такой скорости всё равно не было.

>Ну будет система грузиться не 20, а 10 секунд (походу, сферический в вакууме вариант).

У меня было 30 с OpenRC, стало 10 с systemd в реальной ситуации на моём нетбуке, который не сферический и не в вакууме.

Между скоростью загрузки и возможностью контроля системы я выберу последнее.

В systemd не меньше возможностей контроля системы, чем в SysVinit.

И да, если ты тут кричишь, что скрипты лучше, чем код на C, потому что у тебя они каждый день отваливаются и их приходится исправлять, но зато их можно не компилировать, то почему пользуешься другими бинарными программами? Вдруг WM упадёт, это ж надо лезть в исходники, пересобирать, чтобы исправить баг. А ты перепиши свой WM на bash'е (а заодно и все другие программы, включая bash и coreutils), тогда же можно будет исправлять код, не собирая.

> И да, если ты тут кричишь, что скрипты лучше, чем код на C, потому что у тебя они каждый день отваливаются и их приходится исправлять

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

Вдруг WM упадёт, это ж надо лезть в исходники, пересобирать, чтобы исправить баг.

Когда падает WM, я уже нахожусь в рабочей системе. С компилятором и доступом в сеть.

упадёт

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

>Когда падает WM, я уже нахожусь в рабочей системе. С компилятором и доступом в сеть.

Если будет баг в одном из бинарников в /lib/systemd/systemd-*, то система загрузится, как обычно, просто один сервис будет в состоянии failed. Компилятор и сеть будет.

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

Я писал про невозможность вмешать в логику работы.

Это нужно? В логику работы бинарных собранных программ без компилятора и исходников всё равно не вмешаться. А в логику работы init-скриптов зачем вмешиваться?

>ну к арчу и опенрц прикрутить было проблемным в нём всё-таки несколько ортодоксальная для большинства линукс дистров система запуска..
http://www.archlinux.org/packages/core/x86_64/sysvinit/ ← ты про это?

> Оно событийно-ориентированное, поэтому загрузка повесится, но getty и *dm запустятся, работать можно будет.

В теории. А на практике он виснет без getty и dm. Проверено. Пока несколько строк из fstab-а не были убраны - системо не грузилось.

/etc/mtab - это символьная ссылка на /proc/mounts. Это рекомендация по использованию systemd. Иначе просто он не все маунты запишет в /etc/mtab.

Тоже леннарт придумал? А теперь смонтируй мне livecd.iso через loop и посмотри, как этот образ будет отображаться в выводе mount при символической ссылке, ага. А потом сделай так, чтобы по `umount livecd.iso` этот образ отмонтировался. Для отдельных редких случаев симлинка хватит. Но делать это рекоммендацией - это нужно было не головой думать.

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

Давайте выпилим скрипты на баше и заменим их скриптами на systemd. Тогда, если в скриптах на systemd будет чего-то не хватать - мы захардкодим это в systemd. Ты те юниты видел? Это что-то типа .desktop-файла, там ничего вписать невозможно. Попробуй написать мне юнит, который при загрузке, если устройство с определенным ID есть в USB - берет с него ключ и использует для подключения шифрованного раздела, а если нет - подключает в это же место другой шифрованный раздел с хардкодом вбитым ключом.

Как это сделать в systemd? Написать скрипт на баше, и запустить его из скрипта systemd? А чем тогда скрипты systemd лучше скриптов на баше? И нафига тогда нужен systemd?

> Там и SysVinit, и systemd не нужны. Для этих целей есть busybox.

А есть ли хоть один случай, где systemd нужен?

не дает НИ ОДНОЙ НОВОЙ возможности взамен.

Ну толсто же. Я же уже давал эту ссылку: http://www.opennet.ru/opennews/art.shtml?num=30412

Повторю вопрос из другого сообщения: Есть ли в мире хоть одна реальная задача, которая с systemd решается лучше, чем без него? Если нет, то нахрена оно надо?

Поставил этот systemd себе на Arch и вполне рад. Скорость запуска увеличилась раза в 2, а выключения раз в 5. Помимо того, что пришлось около получаса вникать в устройство и написать пару unit-файлов никаких проблем не возникло (все rc.conf-парсеры выключил и перевёл настройки в нативный вид).

хоть одна реальная задача, которая с systemd решается лучше, чем без него?

Да, быстрый запуск системы, например.

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

Показываю минусы:

1. Оно глючит

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

3. Оно не решает ни одной новой задачи

И зачем такие радости?

>> хоть одна реальная задача, которая с systemd решается лучше, чем без него?

Да, быстрый запуск системы, например.

Да не запускает systemd систему быстро - он просто размазывает время старта, и быстрее выводит систему к login prompt.

> Ну будет система грузиться не 20, а 10 секунд (походу, сферический в вакууме вариант).

Это, пока что, тоже в теории. В реальности systemd сливал по скорости upstart-у и выигрывал у sysvinit только за счет параллельности при большом количестве сервисов. Правда, это было пол года назад, есть желающие повторить тест сейчас?

>быстрее выводит систему к login prompt.

Это же и надо, чтобы юзер смог быстрее начать работать.

> Это же и надо, чтобы юзер смог быстрее начать работать.

У меня в арче всё это есть без systemd. ЧЯДНТ?

Есть мнение, что с ним будет быстрее.

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

Я отвечу за него. Потому что бинарные программы решают свою задачу, и делают это хорошо. Задача скриптов - это либо объединить функциональность нескольких программ (сгенерировать ключ при первом запуске sshd), либо выполнение различных условных операций (вроде `/etc/init.d/iptables panic`).

Вдруг WM упадёт, это ж надо лезть в исходники, пересобирать, чтобы исправить баг. А ты перепиши свой WM на bash'е

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

А теперь смонтируй мне livecd.iso через loop и посмотри, как этот образ будет отображаться в выводе mount при символической ссылке, ага. А потом сделай так, чтобы по `umount livecd.iso` этот образ отмонтировался.

УМВР. Именно так и делаю. Кстати, в coreutils запилили фичу, что теперь не обязательно передавать '-o loop', mount сам определяет.

max@laptop ~ $ sudo modprobe loop
max@laptop ~ $ sudo mount /mnt/home/max/Программы/iso/archlinux-2010.05-netinstall-i686.iso /mnt/tmp0
mount: warning: /mnt/tmp0 seems to be mounted read-only.
max@laptop ~ $ mount | grep '/mnt/tmp0'
/mnt/home/max/Программы/iso/archlinux-2010.05-netinstall-i686.iso on /mnt/tmp0 type udf (ro,relatime,utf8)
max@laptop ~ $ sudo umount /mnt/tmp0
max@laptop ~ $ mount | grep '/mnt/tmp0'
max@laptop ~ $

Это что-то типа .desktop-файла, там ничего вписать невозможно

Там можно вписать те же команды, что и в скрипт. Не поверишь, ExecStart= можно написать несколько раз.

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

Можно даже больше. Чтобы просто так монтировался «другой шифрованный раздел», а при вставке флешки он размонтировался, а туда монтировался первый с ключом на флешке. А при вынимании флешки первый можно размонтировать, а второй смонтировать. И на юнитах это будет проще: юнит с зависимостью от нужного *.device, в ExecStartPre написать размонтирование второго, в ExecStart написать монтирование первого, в ExecStop написать размонтирование первого, в ExecStopPost монтирование второго. И не надо проверять, не сфейлила ли команда, systemd сам проверит. А если же надо просто при загрузке 1 раз смонтировать, то просто те команды, которые были в bash-скрипте, записать в ExecStart'ы, при этом тоже не надо проверять на ошибки.

> Поставил этот systemd себе на Arch и вполне рад. Скорость запуска увеличилась раза в 2, а выключения раз в 5.

Поставь себе upstart на Arch, и получишь ту же самую скорость, но без лишних глюков.

Кстати, а слабо провести тестирование полной загрузки для systemd и для upstart от включения и до странички в браузере? Примерно как тут: http://www.youtube.com/watch?v=88aal60AqBs

ExecStart= можно написать несколько раз.

Вроде как, нельзя, но есть ExecStartPre и ExecStartPost, которые можно.

>Проблемы появились именно с приходом systemd.

Пруф или не было. Или хотя бы примеры проблем с systemd.

Я не столкнулся с проблемами с systemd. Когда я начал им пользоваться несколько месяцев назад, надо было только написать пару юнитов для cups, gpm и ещё чего-то. Ничего не глючило.

Upstart надо собирать из AUR, да и после знакомства с ним в ubuntu остались не самые приятные впечатления.

>но без лишних глюков.

systemd не глючит. Зато я знаю много людей IRL, у которых бубунта подвисает при загрузке на 2 минуты или не стартуют демоны, или же глючит plymouth. И в upstart нельзя отключить демон (аналог systemctl disable).

> УМВР. Именно так и делаю.

У тебя /etc/mtab - не симлинк. О чем и речь.

Можно даже больше.

А мне не нужно больше. Мне нужно именно так. Я НЕ ХОЧУ чтобы он перемонтировался потом, даже если я вставлю флешку. Могу я это получить с помощью systemd? Как?

С помошью sysvinit мне доступны оба варианта: «Меньший» - написанием скрипта в /etc/init.d/ и «больший» - написанием скрипта и добавлением его в правила udev. А в systemd я могу написать только «больший» вариант, видимо, потому что «меньший» для него слишком мизерный, и systemd не соизволит снизойти до него.

А если же надо просто при загрузке 1 раз смонтировать, то просто те команды, которые были в bash-скрипте, записать в ExecStart'ы, при этом тоже не надо проверять на ошибки.

Просто. В теории. Напиши это на практике. С условием наличия устройства с нужным ID и извлечением ключа с флешки либо монтированием другого раздела если ключа нет. На bash-е это действительно просто. А на systemd это хотя бы возможно без запуска внешнего скрипта?

[quote]У тебя /etc/mtab - не симлинк. О чем и речь.[/quote] [code]max@laptop ~ $ ls -l /etc/mtab lrwxrwxrwx 1 root root 12 Май 24 19:56 /etc/mtab -> /proc/mounts[/code] Если первая буква в правах доступа 'l' - то что это, если не симлинк? [quote]А в systemd я могу написать только «больший» вариант, видимо, потому что «меньший» для него слишком мизерный, и systemd не соизволит снизойти до него.[/quote] Читать умеешь? Сразу же после этой фразы процитировал мою, содержащую ответ. [quote]Напиши это на практике. ... На bash-е это действительно просто.[/quote] Давай мне на баше, я переведу.

> К счастью, я с этим багом не столкнулся.

Повезло. Его никто не исправил:
systemd: native shutdown killall does not skip mdadm processes

И это - только один из многих багов:
ISO images are not loop mounted at boot
bind mount entries in fstab result in duplicate mounts

Не считая банального маразма, вроде:
Output of 'systemctl --all' pipes through 'less' by default

Ни одной из этих проблем не возникло бы, если бы Леннарт не пытался изобрести гибрид лопаты и велосипеда с квадратными колесами.

>systemd: native shutdown killall does not skip mdadm processes

Дык оно же только с LVM будет. У меня нет, поэтому и не видел. И это вовсе не «когда systemd снимал питание раньше, чем ядро успевало отмонтировать файловые системы», а совсем другой баг.

ISO images are not loop mounted at boot

bind mount entries in fstab result in duplicate mounts

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

Сейчас ещё проверю, работают ли они.

Проверил. Вот из fstab:

/mnt/home/max/software/iso/archlinux-2010.05-netinstall-i686.iso /mnt/tmp0 auto loop 0 0
/usr/bin /tmp1 bind bind 0 0

max@laptop ~ $ mount | grep tmp1
/dev/root on /tmp1 type ext4 (rw,relatime,user_xattr,acl,commit=600,barrier=1,data=ordered)
max@laptop ~ $ mount | grep tmp0
/mnt/home/max/Программы/iso/archlinux-2010.05-netinstall-i686.iso on /mnt/tmp0 type udf (ro,relatime,utf8)

ISO images are not loop mounted at boot

bind mount entries in fstab result in duplicate mounts

[quote]/mnt/home/max/software/iso/archlinux-2010.05-netinstall-i686.iso /mnt/tmp0 auto loop 0 0[/quote] Более того, у меня в fstab: [code]UUID=87c547af-543a-4c6d-96eb-a566f59f78f0 /mnt/home ext3 noauto,relatime 0 0[/code] И systemd понял, что надо и /mnt/home смонтировать, чтобы появился образ, и таки смонтировал, несмотря на noauto. Что-то я не уверен, что 'mount -a' так смог бы. Другие маунты с noauto не смонтировал, если что.

>> быстрее выводит систему к login prompt.

Это же и надо, чтобы юзер смог быстрее начать работать.

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

> systemd не глючит.

«systemd not a bug» - это мем на IRC-канале федоры. Примерно на равне с «gnome3 is not a bug, it's a feature».

Зато я знаю много людей IRL, у которых бубунта подвисает при загрузке на 2 минуты или не стартуют демоны, или же глючит plymouth.

А я помогал людям править fstab, из-за которого после перехода на systemd система не грузилась, или висла при загрузке на 80 секунд. Без него - все нормально, а с ним - глюки. И это - не в далеком прошлом, а пару недель назад.

И в upstart нельзя отключить демон (аналог systemctl disable).

Как же ж нельзя? upstart рулит обычными sysv-скриптам. Его главное отличие от классического sysvinit - он умеет запускать программы параллельно. Больше ничего для «быстрой загрузки» не надо.

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

В венде есть эта фича? И да, видел компьютер с частотой процессора в 2 раза больше, чем у процессора моего нетбука, там венда 7 грузится около 20 секунд, потом ещё через 5 секунд появляется форма логина. У меня же 10 секунд загрузки (на процессоре с вдвое меньшей частотой!) + 5 секунд, пока gdm загрузится. Когда я залогинюсь, уже загрузка заканчивается, а когда загрузится гном (ещё пару секунд), уже можно работать.

>upstart рулит обычными sysv-скриптам.

4.2. Там есть /etc/init/, в котором лежат файлы, с виду напоминающие юниты systemd, а на самом деле только напоминающие. Если он рулит lsb-скриптами, то это просто означает режим совместимости, потому что нужный скрипт не переписан под upstart. А чтобы отключить демон, надо переместить файл из /etc/init/ куда-то.

править fstab, из-за которого после перехода на systemd система не грузилась

См. мой пост выше, баги с fstab не словил. Если есть конкретные строки fstab, на которых валится systemd - выкладывайте, с радостью протестирую.

он умеет запускать программы параллельно. Больше ничего для «быстрой загрузки» не надо.

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

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

В венде есть эта фича?

Какая «эта», размазывание времени загрузки? Да, есть.

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

Так, чорт побери, об этом и речь. Что systemd - это велосипед-мутант. Он принес кучу новых проблем, которых не было без него. Все эти проблемы уже давно решены в существующем софте, но Леннарт не был бы Леннартом, если бы сам лично не прошелся заново по всем граблям. Зачем? Потому что это чем-то помогает? Нет, нисколько, просто Леннарт страдает NIH-синдромом. Всегда так было. Такой вот он человек. Но почему остальные должны мучаться с проблемами Леннарта?

Интересно, после выхода Fedora15 на какой дистрибутив ушел Линус?

> Если есть конкретные строки fstab, на которых валится systemd - выкладывайте, с радостью протестирую.

Хотел проверить, даже скачал для этого Fedora-16-Nightly-20110616.09-i686-Live-lxde.iso чтобы потестировать на последней версии systemd. Но, увы, он виснет при загрузке в init 3.

> Для более быстрой загрузки надо вызывать программы при срабатывании событий

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

> (появился девайс - сразу смонтировать, а не подождать все девайсы - потом их все смонтировать).

Это не имеет отношения ни к systemd ни к upstart. Это - работа udev.

> управление через dbus;

А без него никак не обойтись?

Давай мне на баше, я переведу.

DISK=/dev/disk/by-uuid/12345678-abcd-9876-f00d-fedcba987654
if [ -r $DISK ]; then
  MARK=`dd if=$DISK bs=8 count=1 skip=10`
  if [ $MARK == "MagicKey" ]; then
    dd if=$DISK bs=16 count=1 skip=12 | cryptsetup ... && mount /dev/mapper/something /mnt/extra
  else
    mount /dev/sda10 /mnt/extra
  fi
fi

Почему нельзя реализовать такое как запись в fstab + правило для udev? Зачем городить какие-то отдельные скрипты?

>> управление через dbus;

А без него никак не обойтись?

Думаю, что со временем Леннарт сделает в systemd собственный вариант dbus, который, конечно, будет конфликтовать с dbus-daemon, будет глючить при передаче строк с русскими символами и содержать кучу других подобных багов, с которыми Леннарт будет героически бороться.

> Почему нельзя реализовать такое как запись в fstab + правило для udev?

Потому что мне надо не монтирование при втыкании флешки, а чтобы ПРИ ЗАГРУЗКЕ, если в usb есть ключ, оно подключало шифрованный раздел, а если нет - подключало другой раздел в это же место. И никаких перемонтирований потом быть не должно, даже если я воткну флешку. Как это сделать с помощью udev+fstab?

>Это - работа udev.

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

Тогда, поясни логику скрипта: если устройства нет, то ничего не делается, если есть с нужным $MARK то монтируется /dev/mapper/something, а если нет, то /dev/sda10, верно?

Насчёт жесткого диска не знаю, но съёмные носители монтируются им на ура.

> Тогда, поясни логику скрипта: если устройства нет, то ничего не делается, если есть с нужным $MARK то монтируется /dev/mapper/something, а если нет, то /dev/sda10, верно?

В этом примере - да. Если тебе будет проще, попробуй адаптировать для systemd такой вариант:

DISK=/dev/disk/by-uuid/12345678-abcd-9876-f00d-fedcba987654
if [ -r $DISK ]; then
  MARK=`dd if=$DISK bs=8 count=1 skip=10`
  if [ $MARK == "MagicKey" ]; then
    dd if=$DISK bs=16 count=1 skip=12 | cryptsetup ... && mount /dev/mapper/something /mnt/extra && exit
  fi
fi
mount /dev/sda10 /mnt/extra

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

Что значит «не делает»? А как работают udisks и usb_modeswitch?

Беда в том, что как systemd, так и upstart зависят от dbus, так что собрать систему без dbus, которая шустро запускается, оказывается проблематично.