Релиз systemd 230

Хорошо, буде предельно корректен, нуждается в поддержке, но где то 1 человекочас в год.

Огак. А потом этот 1 человекочас в год выливается в такой сюрприз:
https://habrahabr.ru/company/mailru/blog/238475/

И эти люди говорят что-то против системд...

Демон не в курсе что он назапускал? и с bash никоим образом не определить запущен ли демон? 0o0

Иногда это так. К примеру апач плюс корявый CGI. Который иногда остается висеть, даже после смерти апача.

К тонне лапши на баше добавьте с десяток тон «лапшы» на си, из /bin/bash (centos) + unixutils + остальная фигня упомянутая в .sh скриптах.

Эта тонна лапши нужна в скриптах, администрировании, ежедневной работе с системой. сустемд нужен для сустемд.

подход autoexec.bat (sysvinit)

какой autoexec.bat позволяет тюнинговать целиком запуск машины и остановку?

Огак. А потом этот 1 человекочас в год выливается в такой сюрприз:

https://habrahabr.ru/company/mailru/blog/238475/

И эти люди говорят что-то против системд...

ну так а представь что творится в сустемд))

Эта тонна лапши нужна в скриптах, администрировании, ежедневной работе с системой. сустемд нужен для сустемд.

Я выше давал пример про сервер терминалов под линуксами. Системд делает его более реальным (еще-бы была реальная сетевая прозрачность у иксов... А не та жалкая фигня, которая даже у VNC по скорости сосет).

какой autoexec.bat позволяет тюнинговать целиком запуск машины и остановку?

Ок, autoexec.bat + autoshut.bat

ну так а представь что творится в сустемд))

Ну как они доживут до шеллшока так и посмотрим.

А пока код выглядит нормальным. Код PID1 systemd читаем и понятен. И весьма невелик.

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

Я выше давал пример про сервер терминалов под линуксами.

давал ссылку на tiny core или пускался в пространственные рассуждения?

Ок, autoexec.bat + autoshut.bat

еще autorun.bat, т.к. на шелле + coreutils можно программировать и работу системы. Начало, работу и остановку.

Ну как они доживут до шеллшока так и посмотрим.

ну жди, жди :-D

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

Ну ясен пень что не будешь ты сидешь и ждать беспокоясь все время. I want to believe.

давал ссылку на tiny core или пускался в пространственные рассуждения?

И как оно релеватно в плане сервера приложений / сервера терминалов под линуксами? Его можно лишь в качестве тонкого клиента использовать, и то, без фактически всего, что реально нужно в работе.

еще autorun.bat, т.к. на шелле + coreutils можно программировать и работу системы. Начало, работу и остановку.

Огак. И каждый демон вынужден использовать набор костылей daemon(), вести логи своим методом, самостоятельно понижать себя в правах, самостоятельно применять на себя всякие ограничения... И это вместо того, что бы тупо выполнять свою работу и писать лог в stdout/stderr. А остальное пусть делает системная прослойка.

Ну ясен пень что не будешь ты сидешь и ждать беспокоясь все время. I want to believe.

Хех, сейчас sysvinit только в маргинальщине. И как-бы хейтеры не ныли, все юзают systemd. От мейнтенеров до разработчиков софта.

Мне это нытье в сторону systemd vs sysvinit напомнило нытье linux vs unix. Помните чем оно закончилось? Работающих в проде юниксов можно пересчитать по пальцам. Ровно как и вакансий на юниксойдов.

Прогресс, фигли.

И как оно релеватно в плане сервера приложений / сервера терминалов под линуксами? Его можно лишь в качестве тонкого клиента использовать, и то, без фактически всего, что реально нужно в работе.

Ой вей, моя вина. Пропустил слово серверы. Чем здесь поможет сустемд? Обобщи тока, пожалуйста все треды, где об одном и том же говорится, опровергается, и вот просто и честно, чем оно пригодилось бы.

P.S. На остальные реплики не отвечу, фигня всё это. Просто еще одна система инициализации. Да, у редхат много влияния и контроля над разработчиками/разработками, но не получится, если не получилось до сих пор.

А вот что уважаемые могут сказать по поводу такой штуки, как проверка конфигов перед рестартом сервиса? Например, в nginx или isc-dhcp ранее при рестарте\релоаде можно было выполнить проверку конфига и только потом перезапускаться, а systemd такое не умеет (хотя казалось бы, очевидная штука). Приходится писать скрипт-обёртку для рестарта на том же шелле.

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

Поправка - пока не умеет.
Хотя реально проверить можно только наличие конфиги (что из системд, что из шеллскрипта). Содержимое конфиги проверять должен таки демон, который это содержимое понимает.

Ну да, я про это же. Нужна новая директива для юнита, что-нибудь вроде ExecConfigCheck иди ExecRestartPre, куда вписываешь команду и оно выполняется перед рестартом, и в случае негативного результата не пытается перезапустить сервис. Где-то видел на гитхабе старый issue, в котором обсуждение даже не завязалось.

Чем здесь поможет сустемд

Сейчас я делаю сервер терминалов для 1с. Основная киллерфича системд для меня - управление сессиями loginctl. Раньше, когда я пробовал поднять сервер терминалов - я упирался в простую задачу - надежно прибить подвисшую сессию пользователя (включая демонизированные процессы), не затронув его рабочую сессию.


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

К примеру привязка устройства к ситу выполняется одной простой командой:
loginctl attach seat1 /sys/devices/pci0000:00/0000:00:1d.0/usb2 #(простой способ «передать» на другой сит USB-порт)
loginctl attach seat1 /sys/devices/pci0000:00/0000:00:1c.4/0000:04:00.0/0000:05:00.0/sound/card0 #проброс звуковухи на другой сит.
И оно просто работает! Оно само запоминает ситы, оно само настраивает пульсу... Единственное что мне пришлось делать вручную - обвязка вокруг VirtualGL (одна видюха у меня мощная, вторая не тянет)

По сравнению с тем, что мне приходилось творить раньше - небо и земля!

В качестве обкатки на работе - это решение работает у нас в учебном кабинете (проапдейдить 20 компов намного сложнее, чем 10).

Ну да, я про это же. Нужна новая директива для юнита, что-нибудь вроде ExecConfigCheck иди ExecRestartPre, куда вписываешь команду и оно выполняется перед рестартом, и в случае негативного результата не пытается перезапустить сервис. Где-то видел на гитхабе старый issue, в котором обсуждение даже не завязалось.

ExecStartPre=, ExecStartPost= - есть такое уже. https://www.freedesktop.org/software/systemd/man/systemd.service.html#ExecSta...

Это совсем не оно. Если в конфиге опечатка\ошибка, то будет так:

• 1. systemd остановит сервис
• 2. systemd запустит ExecStartPre, зафейлится
• 3. сервис неактивен и поломан.

В случае шелл-лапши, реализуется другой порядок:

• 1. проверяется конфиг
• 2. если ошибка - перезапуск фейлится, на консоль отображается ошибка, но сервис с рабочих конфигом продолжает работать (никто его ещё не убивал)
• 3. если ошибки нет - перезапускается сервис.

Это совсем не оно. Если в конфиге опечатка\ошибка, то будет так:

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

Давайте будем честными - systemd еще пока никто не использует на серверах, его дебют состоялся с убунтой 16.04 lts. Т.к. большинство пользователей centos/debian - эт легаси, они еще на 6/7 сидят, а некоторые крупные российские игроки вообще на 5м. Короче у кого был центос или дебиан - менять релиз не стали. Ну а модные админы сидят под убунтой, где доминировать еще долго будет 14.04 lts. В итоге в боевых условиях пока очень малое число проектов с systemd и реальные впечатления специалистов стоит ожидать на форумах в ближайшие полгода-год.)

Содержимое конфиги проверять должен таки демон, который это
содержимое понимает.

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

Я в частности к тому, что по мере того, как он наберет критическую долю на серверах, он привлечет и внимание хакеров к себе. И, думаю, на этом форуме «решето» напишут еще неоднократно про него.

Давайте будем честными - systemd еще пока никто не использует на серверах,

centos 7, debian 8 и добавилась убунта 1604.
Медленный цикл смены серверов - это нормально.
Как я и говорил - примерно так-же было с юниксами. И так-же все смеялись с мысли, что линукса вытеснят юникса.

Я в частности к тому, что по мере того, как он наберет критическую долю на серверах, он привлечет и внимание хакеров к себе. И, думаю, на этом форуме «решето» напишут еще неоднократно про него.

Даже защита типа «решето», лучше чем отсутствие защиты в sysvinit.
Впрочем, ни sysvinit, ни systemd (PID1) сеть не слушают. Так-что уязвимости могут быть только локальные. И тут у системд больше надежности за счет плотной работы с cgroups.

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

Релиз systemd 230 (комментарий)

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

Ога. А теперь добавь мне сюда проверку того, что все точки монтирования для ${datadir}, объявленные в fstab, примонтировались.

больше всего бесит когда сервер запустился и сеть поднялась, а sshd не запустился потому что что-то там с маунтпоинтами не так или еще какая незначительная проблема

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

Даже защита типа «решето», лучше чем отсутствие защиты в sysvinit.

а много было уязвитмостей в sysvinit и init(pid1)? спрашиваю ради интереса.

больше всего бесит когда сервер запустился и сеть поднялась, а sshd не запустился потому что что-то там с маунтпоинтами не так или еще какая незначительная проблема

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

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

Из того, что так делают все, не следует, что так делать правильно.

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

И? polkit в помощь.

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

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

Из того, что так делают все, не следует, что так делать правильно.

Из того, что многие фанбои пользуются systemd, не следует, что так делать правильно.

Я ничего не упустил? :)

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

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

Другими словами,

shell и sysvinit <...> прекрасно настраивается

Ложь.

Из того, что многие фанбои пользуются systemd, не следует, что так делать правильно.

Конечно, не следует. Это следует из других утверждений.

Я ничего не упустил?

Всё упустил. Впрочем, ничего неожиданного.

«Разница с пульсаудио весьма наглядна. У нее аналог alsa, которая может 80% всего что нужно из коробки.» Ты либо жирный тролль, либо дебил.

По сравнению с тем, что мне приходилось творить раньше - небо и земля!

а что ты творил раньше?

shell и sysvinit <...> прекрасно настраивается

Ложь.

сустемд уже научился условному запуску по коду возврата?

Условному запуску чего по коду возврата чего?

Шлангом прикидываешься? Мы это в каждой теме сустемд обсуждаем :-D

Не помню. Сформулируй задачу и я сформулирую решение.

нужно запустить демона с опциями, которые зависят от кода возврата запущенного до него другого демона.

Так «запущенного до него демона» или «от кода возврата»? Демоны, знаешь ли, на то и демоны, чтобы в памяти висеть...

если демон не запустился, код возврата играет дальнейшую роль для запуска следующего демона.

A.service:

[Service]
ExecStart=/path/to/daemonA

[Unit]
OnFailure=B.service

B.service:

[Service]
Exec=/bin/bash -c '\
case $(systemctl show --value -p ExecMainStatus B.service) in \
42) ARGS=("-A") ;; \
*) ARGS=("-B") ;; \
exec /path/to/daemonB "${ARGS[@]}" \
'

Выступления intelfx анекдот напомнили.

- Владимир Владимирович, сколько будет дважды два?
- Буду краток. Вы знаете, буквально на днях я был в Российской Академии Наук, провёл беседу со многими учёными, в том числе молодыми, кстати, очень грамотные ребята. Так вот мы обсудили, в частности и данную проблему, поговорили о текущей экономической обстановке в стране; они так же рассказали о своих планах на будущее. Конечно, в первую очередь их волновала проблема востребованности; не менее остро встал и вопрос по ипотечным кредитам, но могу заверить, все эти проблемы решаемы и мы направим все усилия, чтобы решены они были в самом ближайшем будущем. В том числе это касается и темы, затронутой в вашем вопросе.

Если ты не умеешь пользоваться инструментом и в результате этого он тебе мешает, это не проблема инструмента.

Расскажи это создателям дистрибутивов, хз почему они так не делают.

Из того, что так делают все, не следует, что так делать правильно.

Объясняет почему не все хотят использовать systemd.

И? polkit в помощь.

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

Расскажи это создателям дистрибутивов, хз почему они так не делают.

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

Или, как вариант, в твоём дистрибутиве сеть инициализируется на sysinit.target с DefaultDependencies=no, а sshd — на multi-user.target. В этом случае действительно стоит спросить у мейнтейнеров, какого хрена они сделали и почему они считают, что сеть на полумёртвой системе поднять можно, а sshd нельзя.

Объясняет почему не все хотят использовать systemd.

Объясняет. Но мы вроде не об этом говорили...

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

Да, это более гибкий аналог sudo и для него пишут правила на JS. Собственно, за счёт чего он и является «более гибким». За что можно хейтить polkit — мне решительно не понятно.

Exec=/bin/bash -c '\
\
\
... 100 строк кода ...
\
\
'

Спасибо проблевался. А вообще забавно, доказывая что сустемд настраивается лучше чем sysvinit + shell ты приводишь shell :) Итак, следуем твоему совету. Мы же говорим о том, как сустемд лучше настраивается чем инит и шелл, да? Начинаем скрипт:

Exec=/bin/bash -c '\
case "`uname`" in \
 IRIX*)
     ...

Exec=

case «`uname`» in \ IRIX*)

systemd же привязан к Linux (и gcc).

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

systemd же привязан к Linux (и gcc).

кроме ядра, еще и к redhat-экосистеме, т.к. даже не в каждом дистрибутиве GNU/Linux оно работает.

Естественно, я использую шелл для реализации произвольных частных случаев, не предусмотренных в systemd. В этом нет ничего плохого — в моём примере вкрапления императивной логики носят ограниченный вспомогательный характер, в то время как основную работу (отслеживание процессов, хранение кода возврата, запуск обработчика) всё равно делает движок в systemd. И, разумеется, это удобнее и лучше, чем делать всё руками (как в sysvinit).

Кстати, помнишь свой юникс-вей? Separation of mechanism and policy в чистом виде.

А теперь приведи решение для sysvinit или BSD-style init, и мы посмотрим, в каком нужно писать меньше кода.

Естественно, я использую шелл для реализации произвольных частных случаев, не предусмотренных в systemd.

Так вот, init + shell настраивается лучше systemd. И даже больше, init + shell настраивается лучше чем systemd + shell.

В этом нет ничего плохого — в этом случае вкрапления императивной логики носят ограниченный вспомогательный характер, в то время как основную работу всё равно делает движок в systemd.

что для него «основная работа»? :-D

Кстати, помнишь свой юникс-вей? Separation of mechanism and policy в чистом виде.

bloatware в чистом виде. udev впендюрим, там свой dsl, тут (ini конфиги) свой, для расширения (shell) третий, и пусть всё это убого и недоразвито, но зато выглядит глобальненько.

А теперь приведи решение для sysvinit или BSD-style init, и мы посмотрим, в каком нужно писать меньше кода.

Какая разница сколько кода, если в твоём случае он работает только на одной платформе одного вендора? Легче сразу написать один скрипт для всех. Вон, в сустемд поддержка init-скриптов не просто так осталась. Или выпилили уже?

P.S. rc.cups. Осилишь переписать не теряя функциональности, пусть даже с большим(!) кол-вом кода - дай знать)

что для него «основная работа»?

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

bloatware в чистом виде. udev впендюрим, там свой dsl, тут (ini конфиги) свой, для расширения (shell) третий, и пусть всё это убого и недоразвито, но зато выглядит глобальненько.

Перестаём разводить демагогию и формально отвечаем на конкретные вопросы:

1. Что такое bloatware?
2. Почему systemd — это bloatware?
3. Почему bloatware — это плохо?

Какая разница сколько кода, если в твоём случае он работает только на одной платформе одного вендора

Количество кода/конфигурации, требуемое для решения задачи — это вопрос нашего спора. Твоё съезжание с темы разговора выглядит очень прямолинейно и глупо.

> Так вот, init + shell настраивается лучше systemd. И даже больше, init + shell настраивается лучше чем systemd + shell.

Я только что обосновал, почему это не так. Жду опровержений в виде решения твоей же задачи на sysvinit + shell. Съезжать с темы бессмысленно.

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

тогда зачем там udev?

Перестаём разводить демагогию и формально отвечаем на конкретные вопросы:

ты разве не согласен что у сустемд свой формат конфигов, удава свой?

Что такое bloatware?
Почему systemd — это bloatware?
Почему bloatware — это плохо?

https://people.debian.org/~stapelberg//2013/06/09/systemd-bloat.html

Проверить можно легко: ldd, ps, etc.

Количество кода/конфигурации, требуемое для решения задачи — это вопрос нашего спора.

Напоминаю исток:

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

shell и sysvinit <...> прекрасно настраивается

Ложь.

Я тебе показал что shell + sysvinit прекрасно настраивается, и даже лучше сустемд.

Я только что обосновал, почему это не так.

угага, обосновал он :-D Что настраивается уродливыми хаками в ini конфигах? В ограниченном режиме? :-D

Съезжать с темы бессмысленно.

хочешь съехать - съедь. Перестань только приписывать мне этот мотив)

тогда зачем там udev?

На протяжении всей подветки мы говорим про init (PID 1). udev в него не входит.

ты разве не согласен что у сустемд свой формат конфигов, удава свой?

Конечно, согласен. Какое отношение это имеет к bloatware?

https://people.debian.org/~stapelberg//2013/06/09/systemd-bloat.html

Текст по этой ссылке, вообще-то, опровергает твою цепочку рассуждений.

Я тебе показал что shell + sysvinit прекрасно настраивается, и даже лучше сустемд.

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

Пока ты этого не сделал — я утверждаю, что решение этой задачи на sysvinit будет объёмнее, что подтверждает мои исходные слова.

На протяжении всей подветки мы говорим про init (PID 1). udev в него не входит.

когда выгодно - входит, когда невыгодно - невходит.

Какое отношение это имеет к bloatware?

perceived bloat can occur from the software servicing a large, diverse marketplace with many differing requirements.

Текст по этой ссылке, вообще-то, опровергает твою цепочку рассуждений.

Вообще-то подтверждает. Стоит внимательно присмотреться к опровержениям, они в твоём духе.

Где?

там, где ты переписал rc.cups.

а на тот кусочек на:

sv check a
case $? in
...