Чем плох systemd?

Вот я точно также. Не понимал негодования.

Он слишком сложен. Другие init-системы (даже пресловутый SysVinit, не говоря о более современных типа runit) не требуют многочасового изучения манов для написания «юнитов», достаточно лишь беглого ознакомления и знания bash.

Ну не аргумент же! Точно так же можно сказать - SysVinit слишком сложен. Systemd не требует многочасового изучения манов по командам bash для написания сервисов, достаточно беглого ознакомления и знания ini.

Вообще, у systemd, как мне кажется, одна из главных проблем - это неочевидные дефолты и неочевидное поведение во многих местах. Для примера:

• Крайняя тема про баг с цифрой вначале имени пользователя. После объяснения, текущее поведение можно более-менее понять, но дефолт неочевидный.
• Семейство команд Exec* поначалу путаешь с башем, но подстановка переменных $ENV и ${ENV} там работают совершенно по-другому, не поддерживаются пайпы и перенаправления.
• Эскейпинг символов - да у них даже тулза отдельное для этого есть. Особенно плохо смотрится для mount-сервисов.
• Механизм override параметров - одни параметры нужно сначала обнулять (ExecPre=) и только потом задавать новые. А в некоторых случаях - нельзя обнулять. Опять же, после объяснения, почему такое поведение - тоже кажется логичным.
• Недавно столкнулся - через /etc/security по-старинке выставил лимиты, а systemd их переопределил в свои дефолты. Тоже было не приятно.

Точно так же можно сказать - SysVinit слишком сложен. Systemd не требует многочасового изучения манов по командам bash для написания сервисов

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

Потому что вы смотрите на управление сервисом с точки зрения сисадмина, я с вами частично согласен. Но сейчас всё склоняется в сторону того, что админ делает только запускалку сервисов, а сервисами управляют разработчики\девопсы. Разработчику досконально знать баш необязательно, я знаю людей, которые пишут прекрасный код на своих ЯП, но когда касаются баша - получается такая жесть... Вот им проще добавить ini-файл, да ещё бонусом поиметь возможность запуска через этот ini-файл на многих дистрибутивах.

Интересует, почему все так не любят systemd

Прямо вот недавно кто-то дал в одной из недавних веток про systemd исчерпывающий ответ: systemd не имеет отношения к https://ru.wikipedia.org/wiki/Философия_UNIX

Ну согласись, этим чертовым композиторам до fvwm и wmaker - как до луны, а одиночка запилить композитор не может.

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

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

Если разработчик сервиса вменяемый, то так будет и с sysvinit: он просто добавит имя в стандартный шаблон.

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

местный работеик RH отвечала, что чтожеделать

А мысли чинить сервис у него совсем не было ?

Ну согласись, этим чертовым композиторам до fvwm и wmaker - как до луны

Не соглашусь. fvwm, конечно, хорош, но i3/Sway тоже неплохи и тоже вполне себе кастомизируемы до неузнаваемости, впрочем я предпочитаю awesome. wmaker — вообще какой-то монстр франкенштейна.

а одиночка запилить композитор не может

Sway запилил одиночка. Есть либа wlc, берущая на себя основную часть низкоуровневой фигни.

Попробуй привязать в CentOS 7 любой сетевой сервис к IP-адресу (в конфигах сервиса) и сделай reboot.

«Ты всё поймешь и всё увидишь сам!» (с)

Там продакшен, сисадмин не чинитель, автор давно ушёл.

надо заставить пару служб дождаться конфигурации сети

Прописать в зависимости systemd-networkd-wait-online, например. У NetworkManager что-то такое тоже есть. Но тогда и сеть должна рулиться этим же.

Именно, а если NM не используется по различным причинам? :)

Например, это сервер со статически прописанными IP-адресами и ОЧЕНЬ нехочется, чтобы в результате глюка NMа (а он очень любит глючить, особенно, на виртуалках) потерялась сетка?

Я свой поддиванный сервак на Debian 8 перевел на systemd-networkd. Пока булькает.

Проблема возникла, когда я с сетевыми мостами чудил. Загрузка зависла на ожидании онлайна. Грузился с recovery и правил конфиги, чтобы поднималось правильно.

Тут один хрен два стула. Или пилить сервисы так, чтобы они нормально стартовали без сети и нормально обрабатывали изменение её конфигурации, или вот такое подпорки со стороны системы.

Философия UNIX - мертворожденное говно и не нужно.

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

Не менее половины людей не знает что такое линукс. Корпорации это волновало мало

Проблема эта давно известна: минимум полтора года только багрепорт на memcached в трекере центоси висит.

Основная трабла в том, что systemd не ждет корректного завершения network.target и стартует все зависимые сервисы «не глядя».

Когда сервис по дефолту стартует с привязкой ко всем интерфейсам вида *:port, то он без проблем запускается (по той простой причине, что lo 127.0.0.1 уже есть). Но вот как только сервис при загрузке системы хочет привязаться к конкретному IP, возникает печалька...

Как следствие, торчащие по *:port во все стороны сервисы необходимо прикрывать файрволлом (а то бяда-бяда и злые кулхацкеры). Отсюда и мертворожденный firewalld с изначальным принципом «запрещено всё что не разрешено».

Я для себя лично нашел такой вариант:

1. Убиваю NM, все интерфейсы прописываю статикой, никаких DHCP.

2. В сервисах systemd меняю строчки «After=network.target» на «After=network-online.target» (включая и sshd.service и rc-local.service)

Минус такого решения в том, что при апдейте systemd, вероятно, эти файлы перезапишутся назад и всё опять перестанет автоматически стартовать при перезагрузке.

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

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

Там продакшен, сисадмин не чинитель, автор давно ушёл.

А что это за продакшен с неподдерживаемым кривым ПО ? А что там ещё есть ? :-)

Философия UNIX - мертворожденное говно и не нужно.

Для тебя есть Windows. vq156, для тебя - тоже.

Я не знаю. Но такие ситуации описывались, как одна из основных причин systemd

В кои-то веки вменяемые придирки к systemd, а не фанбойское кукареканье умственно отсталых.

А что это за продакшен с неподдерживаемым кривым ПО ?

Интересный вопрос от пользователя OpenVZ в продакшене.

Минус такого решения в том, что при апдейте systemd, вероятно, эти файлы перезапишутся назад и всё опять перестанет автоматически стартовать при перезагрузке.

Документацию читать попробуй.

за такие косяки стоило бы отрубить леннарту хвост

В сервисах systemd меняю строчки «After=network.target» на «After=network-online.target» (включая и sshd.service и rc-local.service)

Так это не он туда прописал непоходящие таргеты.

Но такие ситуации описывались, как одна из основных причин systemd

Я знаю. И это, считаю, одна из главных причин определения того, что systemd - говно. Не только идёт в разрез с идеологией, но ещё и осознанно провоцирует написание говнокода. А эти падения, в львином количестве случаев, всякие remote code execution.

Интересный вопрос от пользователя OpenVZ в продакшене.

В каком это месте OpenVZ неподдерживаемый ? И в каком кривой ? Что-то я не видел, чтобы что-то регулярно падало/отваливалось/перезапускалось.

Вот тут я с тобой согласен. Но если у тебя УЖЕ всё крутится, и крутится уже давно, и обвеса немало, то миграция будет нелёгкой. Естественно, если ты начинаешь с нуля, то там уже пофиг, какой инит, а я говорю именно о миграции, причём о принудительной (когда дистр меняет инит без возможности оставить часть скриптоты на старой логике).

Чем плох systemd?

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

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

причём о принудительной

люблю такую постановку вопроса: админов принудили читать маны

а о принуждении разработчиков и майнтейнеров поддерживать громадную кучу мусора по причине отсутствия у админа умения читать речи не идёт?

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

На wlc автор забил к сожалению.

На wlc автор забил к сожалению.

Да? А давно? Последний «релиз» был 2 месяца назад, коммиты есть (3 дня назад последний), хоть и не от изначального автора. Живёт вроде…

Это ЛОР (и Интернет, это в принципе не только для лора справедливо), здесь ненавидят ...

В посте есть много лицемерия, так как systemd стоит отдельно, из далека заметным и выделяющимся особняком.

Да ни чем не плох. Это просто старый жирный Линукс потихоньку подыхает и гниет. Его поддержка стоит все дороже и дороже.

Скоро мы увидим новенькие маленькие Unix-системы на микроядре.

Ну изначальный автор забил.

Сейчас им разработчик sway занимается. Ессно это замедлит разработку что влц, что свей.

люблю такую постановку вопроса: админов принудили читать маны

В каком мане описывается поведение кривой поделки от Лёни в случае имени пользователя, начинающегося с циферки, к примеру? Может быть чтение манов, как и программирование, не осилил сам Лёня? Впрочем, вопрос риторический, ибо Лёня в обсуждении бага с удалением файлов по маске в этом сам признался.

а о принуждении разработчиков и майнтейнеров поддерживать громадную кучу мусора по причине отсутствия у админа умения читать речи не идёт?

Вот же бедные разработчики: наклепали своих поделок, а потом нужно их поддерживать. Ужас какой. Лёня мастерски решил эту проблему и теперь в ответ на любой эпический багрепорт по его кривой поделке пишет что так исторически сложилось и закрывает с пометкой NOT A BUG, лол.

Полегчало?

Полегчало?

Нет, я ещё не сходил.

Минус такого решения в том, что при
апдейте systemd, вероятно, эти
файлы перезапишутся назад

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

Зато сколько насрал уже!

Когда запаковываешь пакет, очевидно легче написать
юнит, чем делать целые танцы на баше с демонизацией

Чем написать хороший демон ты хотел сказать ? Потому как никаких танцев для демона не нужно, его нужно просто запустить. Всякие обработать pidfile и т.п. - это его, демона, задача, а никакого не bash. А вот если демон написан руками из задницы, то да, тогда только такое же рукозадое приложение и спасёт.

Плюс уследить за зависимостями.

Это всё давно продумано и придумано.

Это хорошо для программы, что она привлекает такой интерес. Гораздо хуже, если бы ее молча игнорировали. На ЛОРе, где вообще не принято открыто выражать похвалу, травля и шельмование может быть формой скрытого одобрения.

Он плох тем, что совершенно забивает на UNIX-way. А неюниксвейный линукс — та же самая говновенда!

Посмотри, до чего бубунта скатилась. Уже и не отличить по паршивости какую-нибудь спермерочку от бубунты!!!

А я разве ХОЧУ использовать systemd? Нет, не хочу. И изначально был очень против. Меня вполне устраивают BSD-like и SystemV системы инициализации.

И львиная доля сообщества была против systemd.

Другое дело, что разработчики пихают эту убогую поделку неудачника и дебила леннарта куда ни попадя.

Как результат, ставлю я CentOS 7 minimal. Делаю yum install memcached, добавляю в OPTIONS в /etc/sysconfig/memcached " -l 192.168.10.15" - и сервис у меня не стартует при перезагрузке вирты. После чего приходится перековыривать 15 страниц выхлопа гугла, чтобы найти кривое, но работоспособное решение.

Вопрос: таки это леннарт дебил конченый или всё сообщество?

Вопрос: таки это леннарт дебил конченый или всё сообщество?

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

Зато сколько насрал уже!

Лёня? Да, это ещё тот говнодел.

Я - пользователь системы. Мне ультрафиолетово, что там напихали укурки.

Мне нужно, чтобы сервис работал. Я всё делаю по инструкции. Но сервис не работает.