Systemd за и против (тихо мирно и спокойно)

Тема интересная.

Сам systemd не трогал, но присматриваюсь.

Соображения:
+ Быстрая загрузка
- Бинарные логи. Это коренным образом идет поперек основных Unix принципов, на которыз все зиждется. Профита от этого - 0, по крайне мере пока мы не ставим серваки в google.

И еще. Я считаю что основная killing-фича unix-мира - это возможность выбора. То, что в дистрах НАВЯЗЫВАЮТ systemd - это само по себе вред. И это не проблема systemd, это проблема дистров.

Да отличное поделие, в теории.

Особенно отличны бинарные логи.

Это каким образом упавший демон должен сам себя поднять?

Делается запросто. Если даже в демоне это не предусмотрено, делается простым скриптом-оберткой. Да и стандартные средства для этого есть:
man inittab
Искать: respawn

делается простым скриптом-оберткой

Вот спасибо.

man inittab

Чувак четко заявил: «Отслеживание состояния сервисов(...), имхо, дело каждого отдельно взятого сервиса». Какой тут нафиг inittab?

Бинарные логи нормальны.

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

Бинарные логи нечитаемы без фирменных велосипедов. Зачем иниту бинарные логи?

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

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

УМВР на 7-м. ЧЯДНТ?

Да в общем незачем. Но и вреда от них не будет.

Подробности можешь расписать?

> ИМХО у РедХата разные требования к качеству десктопного софта, до которого ему практически нет дела и системы инициализации, от которой зависит^w будет зависеть их интерпрайз. Даде если пишет его один и тот же человек.

Очень хорошая мысль - только мне кажется, у Red Hat и к десктопному софту требования высокие. Все же из него берут новое ПО, а был бы Red Hat'у безразличен десктоп, не брали бы.

Да всё работает из коробки.

После установки systemd, сразу был agetty на первом VT. Юнит для lxdm пришлось вручную добавить, т.к. у меня lxdm не из дистрибутива собран. lxdm пашет на 7-м. Вручную ничего не настраивал там.

Особенно отличны бинарные логи

Гони выхлоп в сислог, делов-то. У меня до недавноего времени так и было, потом понял, что одна фигня и отрубил сислог, оставив journald.

Да всё работает из коробки.

Подтверждаю, getty на 1-м, kdm на 7-м.

ну так об этом и было сказано - это проблемы не слаки :-)

и отрубил сислог, оставив journald.

Ага. А теперь внимание, задача - как грепнуть maillog? Если в с текстовыми логами мы это знаем (ага, grep!) - то с бинарными... Упс?

- Бинарные логи. Это коренным образом идет поперек основных Unix принципов, на которыз все зиждется. Профита от этого - 0, по крайне мере пока мы не ставим серваки в google.

Бинарные логи никаким образом не прибиты гвоздями к systemd.

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

УМВР на 7-м. ЧЯДНТ?

В багзилле федоры есть багрепорты, в которых поцеринг говорит «*dm должен быть на VT 1, это дизайн». А тебе пока везет.

А тебе пока везет.

В чем именно мне везет? В новой версии что-то изменится? Подробнее с этого места.

dm должен быть на VT 1, это дизайн

Поттеринг школоло, да.

То, что в дистрах НАВЯЗЫВАЮТ systemd - это само по себе вред. И это не проблема systemd, это проблема дистров.

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

Успокойся, не навязывают, а выбирают.

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

А пользователь имеет право выбирать себе дистр с более «умными», по его мнению, мантейнерами.

Проблема в том, что система инициализации может быть одним из критериев. Следуя твоему принципу, если есть 10 требований к дистрибутивам, то должно быть 1024 (а то и больше) достойных и различных между собой дистров. К сожалению в реальности это не так. Вывод такой же как и выше: Возможность выбирать должна быть внутри дистра.

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

Если его можно выпилить и при этом все остальное работает - тогда ок.
Давай по фактам: в Арче можно (будет) убрать systemd с сохранением всей остальной не-systemd функциональности?

Разное ПО использует разные подходы. Ярость и сопли в отношении systemd вызваны исключительно тем, что его внедрение распиарено. Подавляющее большинство линуксоидов не знает как работают приложения, которые они используют каждый день, а ведь в каждом ПО есть места, реализованные «плохо» или «хорошо» по мнению какого-нибудь «аналитика» диванного. Но незнание позволяет спокойно пользоваться и не истекать слюнями. «Аналитики» же чаще всего вообще линукс держат в дуалбуте, чтобы смотреть прон и повышать своё ЧСВ. Люди же, которые использую линукс для работы (т.е. для запуска нужного им профессионально ПО), никогда не будут интересоваться, каким скриптом запущена служба. Им пофиг. Сисадмины же разберутся и всё будет нормально.

> делается простым скриптом-оберткой
Вот спасибо.

Вам рюшечки или ехать.

Там, где это действительно нужно, это сделано. Только вот примеров не приведу, так как не знаю где это действтельно нужно. Пример приведете?

Чувак четко заявил: «Отслеживание состояния сервисов(...), имхо, дело каждого отдельно взятого сервиса». Какой тут нафиг inittab?

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

Бинарные логи никаким образом не прибиты гвоздями к systemd.

Что стоит там по-умолчанию?

Я хочу видеть сообщения от ядра и загрузки после загрузки, а вот Леннарт сказал зырить на X server и точка.

Прими разупоринчику и переведи загрузку в 3 ранлевел

Бинарные логи нормальны.

Обоснуй.

Может, пришло время сделать вдоль?

fixed.

Прими разупоринчику и переведи загрузку в 3 ранлевел

То есть теперь чтобы посмотреть логи на соседнем терминале нужно перегружаться? По-моему разупоринчик кому-то другому нужен.

P. S. Я уже не говорю что в некоторых дистрах чудилы-дистростроители сделали runlevel 3 таким же как и 5

Он не должен падать, очевидно же. Если есть проблемы и демон большой и сложный, то какой-нибудь мастер в его составе должен следить за остальными частями(postfix, apache, bind, jabberd2 и т.д.), но я уже писал, что автоподнималка, какой бы крутой она не была - не нужна. Если что-то падает, значит надо выравнивать админу руки и чинить.

Вцелом согласен, но при следующем условии: cисадмин, если ему не нравится поведение программы, должен иметь возможность его (поведение) изменить; или сменить программу (не меняя дистр/не переставляя всю систему).

Сейчас- да. О будущем не знаю.

Вам рюшечки или ехать.

Нам ответ на вопрос «каким образом демон должен сам себя перезапускать без внешней помощи». С рюшечками и ездой все хорошо и без твоей помощи.

+1: (для тех, кому нужен аудит) сервисы стартуют не от имени админа.

+1*0: скорость загрузки, редко существенна. Зато может быть интересен простой способ отключения ненужных сервисов - остановить всё, запустить нужное, задампить состояние оставшегося отключеным, вынести. В sysv нужно было думать, кому что нужно, или выключать по одному и смотреть, что сломалось.

-1*0: Binary Logging Formats. т.н. «текстовые» логи на самом деле тоже «бинарные», формат которых менее формализован, ограничен, но хорошо известен программам. Т.ч. на самом деле проблема в отсутствии/неизвестности более адекватного стандартного формата и стантартных утилит для его обработки. Интересно, DER, например, подошёл бы?

-1*0: скрипты. основное преимущество оных в том, что можно посмотреть/вмешаться в процесс инициализации системы. В канонической системе для этого нужно было знать про init и какой-то командный интерпретатор(обычно sh) с инструментарием (типа coreutils). Теперь - про systemd и тот же (или другой) командный интерпретатор с тем же(или другим) инструментарием. init, конечно, проще, но на этом разница и заканчивается.

А теперь внимание, задача - как грепнуть maillog? Если в с текстовыми логами мы это знаем (ага, grep!) - то с бинарными... Упс?

$ sudo journalctl -a | grep postfix
Aug 16 13:23:30 probook postfix/postfix-script[4807]: starting the Postfix mail system
Aug 16 13:23:30 probook postfix/master[4808]: daemon started -- version 2.9.4, configuration /etc/postfix
$ sudo journalctl _SYSTEMD_UNIT=postfix.service
Logs begin at Thu, 16 Aug 2012 10:22:47 +0400, end at Thu, 16 Aug 2012 13:26:09 +0400.
Aug 16 13:23:30 probook postfix/master[4808]: daemon started -- version 2.9.4, configuration /etc/postfix.

На выбор. Есть еще варианты, но греп никто не отменял:

man systemd.journal-fields

Обоснуй.

Возрази.

Если его можно выпилить и при этом все остальное работает - тогда ок.

В Сусе 12.1 можно выпилить. И в 12.2 вроде можно будет. А можно не выпиливать, а жать F5 на экране GRUB и грузиться с SysVinit.

sudo journalctl

А теперь предложение то же самое, но из какого-нибудь busybox. Ага?

Нам ответ на вопрос «каким образом демон должен сам себя перезапускать без внешне»

Запускается фаза 1, которая запускает фазу 2. Фаза 1 трейсит запуск фазы 2. Как только видит что процесс исчез - перезапускает фазу 2. Это как пример.

Если у тебя в initrd уже лежит systemd, то там должны быть и сопутствующие утилиты. Ты же не додумаешься положить туда systemd без udev.

язабан

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

Вот именно об этом я и говорю.

Он не должен падать, очевидно же.

Нннуууууууу, признаюсь, это было неожиданно.

какой-нибудь мастер в его составе должен следить за остальными частями

А почему обязательно «в его составе»? Какая польза велосипедить?

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

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

Это как пример

Это как костыль. Коль уж мы строим подпорки под падающих демонов, логично было бы сделать один общий костыль, а не сотню индивидуальных.

Возрази.

Кейс 1. Что-то случилось, комп не грузится. Я беру винт, втыкаю его в абсолютно любой комп (с абсолютно любой ОС), открываю лог в любимом текстовом редакторе и анализирую проблему. С бинарным логом так не пройдет.
Кейс 2. У меня есть скрипт, который монитоит содержимое лога на определенные комбинации, на которые есть соответствующая реакция. С бинарным логом - западло, так как мне нужно разбираться в формате лога?
Кейс 3. У меня по каким-то причинам повредился файл с логом. Можно ли бинарный лг прочитать с середины когда он поврежден?

Это - недостатки. Достоинств не вижу.

Вопрос: зачем такое нужно?

sudo journalctl

Можно теперь то же самое с tail -f ? Ну, чтобы новые записи показывало по мере их поступления?

А почему обязательно «в его составе»? Какая польза велосипедить?

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

Это как костыль. Коль уж мы строим подпорки под падающих демонов, логично было бы сделать один общий костыль, а не сотню индивидуальных.

Точно! Это костыль. И просто потому, что это не нужно, даже вредно! Хоть и возможно.

cисадмин, если ему не нравится поведение программы, должен иметь возможность его (поведение) изменить; или сменить программу (не меняя дистр/не переставляя всю систему).

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