Systemd 29

> http://www.opennet.ru/opennews/art.shtml?num=30412 Вот сравнение.

Угу, щас я сравню systemd и mysql по возможностям хранения и манипулирования данными, там будет табличка на сотню строк, в которой напротив mysql будет везде «Да», а напротив systemd - «нет». И что?

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

> TODO: при неудачном запуске сервиса попытаться перезапустить его.

Перезапустит и делов-то.

Кэп в недоумении.

> Зачем монолитный кусок говна с приклеенными костылями, когда есть специализированные узко заточенные утилиты?

fixed

Где можно прочитать вменяемое и читаемое сравнение systemd, upstart и старой системы инициализации по принципу работы и затрачиваемому времени? Что бы можно было бы уяснить суть и при этом не читать 200 страниц манов.

Не могу понять, куда идёт гонка, т.к. у меня Федора 15, Минт 11 и Дебиан 6 грузятся на схожих конфигурациях примерно за равное время.

>И что, это всё уже реализовано, или то что будет?

Это уже есть. Будет больше.

>Пока его версия не достигнет как минимум v1.1, дистры с этой ситемой лучше избегать ИМХО

Уже 29-ая. =) 29>1.1

в харчевики написано, что нужно pak -R syslog-ng && pak -S rsyslog

тред не читал, но не проще ли портировать эппловский launchd, помнится где-то в треде про systemd его хвалили

>Даже если его удалить? Или не установить?

Он вообще-то в зависимостях у systemd. А если установить xterm, а потом иксы удалить?

Или если он просто не запускается, например, из-за кривого апдейта одной из библиотек зависимостей?

А если SysVinit не запускается из-за кривого апдейта? И вообще, хоть раз такое было?

подвешивают загрузку на 10 минут.

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

И этого нельзя сделать из fstab-а, потому что mtab - тоже находится на корне, и в него тоже не должна выполняться запись, корень вообще не должен становиться rw.

/etc/mtab - это символьная ссылка на /proc/mounts. Это рекомендация по использованию systemd. Иначе просто он не все маунты запишет в /etc/mtab. А если сделать эту ссылку, то всё можно сделать из fstab. И даже если по какой-то другой недопричине этого будто бы нельзя сделать, то кто мешает написать юнит для systemd, который будет вызываться до монтирования корня и который будет делать нужные монтирования?

Сейчас я могу это сделать, изменив несколько скриптов в /etc/rc*, потому что это - обычные скрипты на баше. А что мне делать с кодом на С? Перекомпилировать каждый раз, когда я хочу что-то изменить?

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

И зачем для этого systemd?

Не надо - не пользуйся. Я просто привёл первый пример, который пришёл в голову. Таких примеров много, для каждого есть свой костыль, а тут они все в одной программе.

А если это - битая флешка, и мне нужно восстановить с нее файлы, а fsck добьет то, что там осталось? Если в fstab-е было noauto, значит никаких действий быть не должно, и точка. Если не было - он должен монтироваться и проверяться при загрузке.

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

Кстати, был и такой баг в systemd, он монтировал даже то, что отмечено noauto. Это исправили?

Если и был, то исправили, потому что моё noauto оно не монтирует.

>Когда-то был devfs, потом ему на смену пришел udev, если через два года придет newdevd, то в первом варианте его можно будет заменить, а остальные компоненты будут работать, во втором варианте жесткая зависимость от udev сделает систему незагружающейся вообще.

Когда появится какой-нибудь _нужный_ newdevd, который _гораздо лучше_ udev, то он не сразу попадёт на десктопы. Сначала, пока он будет unstable, запилят поддержку в systemd, а когда newdevd попадёт на десктопы к пользователям, systemd уже будет иметь его поддержку.

Дальше, когда нужно собрать компактную систему для роутера или медиацентра - не нужны xinetd, readahead и ulatencyd, в первом случае я могу просто не устанавливать их, и сэкономить на памяти и месте на диске, во втором случае у меня нет такой возможности.

для роутера или медиацентра

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

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

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

>Кэп в недоумении.

Я вот сейчас решил специально проверить. systemctl stop dbus.service, и dbus перезапустился. И в TODO написано: «при неудачном запуске». Неудачном запуске, а не креше или остановке. Остановленный dbus он перезапускает.

systemd как раз реализует основные идеи launchd.

>в харчевики написано, что нужно pak -R syslog-ng && pak -S rsyslog

Ну всё в этом арче через одно место. В Генте работает же и с syslog-ng. А в арче, чтобы заюзать systemd, я должен заменить демон сислога с удобного и привычного на что-то новое.

> systemctl stop dbus.service, и dbus перезапустился.

Охренеть. Говоришь ему английским по черному «останови dbus», и он... перезапускает dbus. *Бурные аплодисменты, переходящие в овации*

Выносите. Закапывайте.

> Он вообще-то в зависимостях у systemd.

EPIC FAIL

А если установить xterm, а потом иксы удалить?

ВНЕЗАПНО: xterm зависит от xlib, а не от иксов.

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

Сначала избавиться от скриптов, а потом изобрести костыльный аналог. Браво.

>перезапускает dbus.

А что ему делать, если systemd управляется через dbus? Если он его остановит и не запустит, то пользователь потеряет управление над демонами. Я вот тоже с SysVinit говорю 'kill -9 1', а он почему-то не останавливается. Какой же плохой этот SysVinit!

> А что ему делать, если systemd управляется через dbus?

ССЗБ

>ВНЕЗАПНО: xterm зависит от xlib, а не от иксов.

Внезапно, xlib != libX11

[code]* app-xemacs/xlib Available versions: 1.14 Homepage: http://xemacs.org/ Description: Emacs interface to X server.[/code]

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

Если бы сначала был systemd, а потом запилили SysVinit, то скрипты были бы костылями. А если хорошо разобраться, то в SysVinit демоны запускаются из inittab. Останавливать/перезапускать/запускать из нельзя. Скрипты написаны, чтобы сделать костыль для обеспечения базовой функциональности, которой нет в SysVinit. К тому же в каждом дистрибутиве свой набор скриптов - свой велосипед со своими багами. А systemd одинаков везде.

>>А что ему делать, если systemd управляется через dbus?

ССЗБ

SysVinit управляется через /dev/initctl. Я удалю /dev/initctl, не смогу выключить компьютер, а SysVinit не пересоздаст этот файл, поэтому он ССЗБ.

Внезапно, xlib != libX11
* app-xemacs/xlib Available versions: 1.14 Homepage: http://xemacs.org/ Description: Emacs interface to X server.

Просто поразительно, что люди даже не могут просто погуглить, прежде чем писать бред.

Если бы сначала был systemd, а потом запилили SysVinit, то скрипты были бы костылями.

Скрипты никогда не были и не будут костылями. Как в systemd встраивается дополнительная функциональность? Я имею ввиду, физически. Как *.so? Если да, то вот это — самый настоящий костыль. Костылище.

К тому же в каждом дистрибутиве свой набор скриптов - свой велосипед со своими багами.

4.2 такое 4.2...

> SysVinit управляется через /dev/initctl. Я удалю /dev/initctl, не смогу выключить компьютер, а SysVinit не пересоздаст этот файл, поэтому он ССЗБ.

Вот именно: основной процесс системы не должен зависеть от ерунды типа dbus. А если у меня на машине вообще dbus не нужна? Если у меня роутер, в котором некому обмениваться потоками говна в формате xml?

Как в systemd встраивается дополнительная функциональность?

Функциональности там дофига и больше. Чтобы он поддерживал какой-то демон, надо просто написать для него юнит (и да, их уже все написали), который пишется проще, чем куча костыльных скриптов для всех дистрибутивов. Какую функциональность там нельзя реализовать с помощью написания простого юнита?

Скрипты никогда не были и не будут костылями.

Всегда были. Они нужны, чтобы можно было запускать/останавливать демоны, ведь хвалёный SysVinit и этого не умеет.

Просто поразительно, что люди даже не могут просто погуглить, прежде чем писать бред.

Ты не поверишь:

$ qfile /usr/include/X11/Xlib.h 
x11-libs/libX11 (/usr/include/X11/Xlib.h)

>А если у меня на машине вообще dbus не нужна? Если у меня роутер, в котором некому обмениваться потоками говна в формате xml?

Если у тебя роутер, установи туда busybox. Я ж не заставляю всех, кто здесь, устанавливать systemd. Не нравится/не подходит - не используй.

> > Как в systemd встраивается дополнительная функциональность?

Функциональности там дофига и больше. Чтобы он поддерживал какой-то демон, надо просто написать для него юнит (и да, их уже все написали), который пишется проще, чем куча костыльных скриптов для всех дистрибутивов. Какую функциональность там нельзя реализовать с помощью написания простого юнита?

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

Всегда были [костылями].

Они нужны, чтобы можно было запускать/останавливать демоны

Поделил на ноль.

ведь хвалёный SysVinit и этого не умеет

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

$ qfile /usr/include/X11/Xlib.h

x11-libs/libX11 (/usr/include/X11/Xlib.h)

Молодец, отлично подтвердил мою правоту. +1 тебе в карму за сообразительность.

>То есть ответа на вопрос ты не знаешь.

Сначала вопрос нормально задай. Если ты о той функциональности, которая в SysVinit обеспечивается bash-скриптами, то в systemd она обеспечивается юнитами, которые писать гораздо проще.

Поделил на ноль.

Ничего я не поделил. Я сказал, что голый SysVinit НИЧЕГО не умеет, даже демоны останавливать. А чтобы это можно было, сделали костыль в виде скриптов.

> Если ты о той функциональности, которая в SysVinit обеспечивается bash-скриптами, то в systemd она обеспечивается юнитами, которые писать гораздо проще.

Я тех функциях, которые:

упразднение загрузочных bash-скриптов и замена схожим по функциональности кодом на C для управления консолью, установки локали, запуска fsck, монтирования файловых систем и др.;

Т.е. если мне потребуется поменять «функциональность для установки локали, запуска fsck» и т.п., мне нужен компилятор?

Я сказал, что голый SysVinit НИЧЕГО не умеет, даже демоны останавливать.

Капитан Очевидность на проводе.

А чтобы это можно было, написали систему управления демонами на sh.

fixed

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

\\в целом системд более гибок в возможностях. и вдимо уже достаточно несыроват

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

Обоснуй.

>Т.е. если мне потребуется поменять «функциональность для установки локали, запуска fsck» и т.п., мне нужен компилятор?

o_O А чего там менять? Чтобы поменять локаль/шрифт/кеймап, есть конфиг /etc/vconsole.conf. systemd ещё и умеет читать конфиг, специфичный для дистрибутива, например, /etc/conf.d/{consolefont,keymaps}. Чтобы поменять порядок fsck, есть последний столбик в /etc/fstab. Больше там нечего менять. Компилятор тут не нужен, нужен только текстовый редактор.

ITT: UNIX-way с инитом на sh vs GNU/Linux-way с жертвованием чего угодно ради скорости и фич.

/run уже везде есть а отдельный /var на десктопе не нужен...

>stat /run  
stat: cannot stat `/run': No such file or directory

А что мне нужно на десктопе — решать мне.

>/run уже везде есть а отдельный /var на десктопе не нужен...

Как, впрочем, и /usr на отдельном разделе :D

> нужен только текстовый редактор.

Если что-то пойдёт не так в загрузочном скрипте, мне нужен только grep something -r /etc и текстовый редактор, чтобы разобраться в проблеме. А вот если что-то пойдёт не так в systemd, мне нужен редактор, исходники и функционирующая инфраструктура сборки: компилятор, binutils, make и остальной зоопарк. Так что не надо тут.

>Если что-то пойдёт не так в загрузочном скрипте

Это ещё раз подтверждает, что скрипты - кривые костыли.

А вот если что-то пойдёт не так в systemd

А вот если что-то пойдёт не так в SysVinit...

>А вот если что-то пойдёт не так в SysVinit...
Он слишком прост.

системд может пускать и твои обыные скрипты что не так? и внезапно там просто переписаны и включены в сам системд часто используемые внешние функции типа sed что увеличивает скорость их выполнения.

\\ очевидно что среднестатическому админу локалхоста тяжело осилить написание юнитов для системд, особенно если они привыкли к опенрц, но тут спасает systemd+openrc вместо sysvinit+openrc

> Это ещё раз подтверждает, что скрипты - кривые костыли.

Lennart — бог. Поклоняйся ему. Только он пишет программы без ошибок. И всегда идеально конфигурируемые под любую задачу. И с абсолютно точной документацией, идеально описывающей каждую мелочь. И еще он не какает.

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

портируй код, которого не видишь... и да не проще

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

Это просто дело привычки. Непривычно - да, но не тяжело.

>Lennart — бог. Поклоняйся ему.

Не сотвори себе кумира.

// И да, кто этот Lennart? =)

блин чувак ты похоже убертелепат.. ты читал хоть одну доку по системд? (читал а не просматривал выдирал из контекста слова и говорил: ненужен, бред, закопать)?

> Обоснуй.

систему управления демонами на sh

он слишком толст.

Чтобы определить, что перед нами говно, его нужно детально обнюхать?

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

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

Ну и? Развивай мысль, развивай.

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

Быстро поискал отзывы

Непривычно сложная система, по сравнению с initscripts, но это окупается гибкостью настроек. А настройки эти у systemd разбросаны по всему /etc и парсеры из arch-systemd-units не все из /etc/rc.conf выбирают. Очень не понравилось то, что иногда машина уходя в ребут зависает. Ну и раз уж скорости загрузки ни секунды не прибавилось, вернулся я обратно на простой, легкий и привычный initscripts.

так и запишем опережающий анализ третьей степени. спасибо за участие в опросе.

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