systemd в продакшене и ентерпрайзе

А им все это не надо. Мне на роутере тоже.

А им все это не надо. Мне на роутере тоже

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

Раньше я писал странное монолитное говно, а недавно вместо этого написал дюжину маленьких systemd-юнитов, друг друга запускающих и попинывающих тоже через systemd. Намазал жирным слоев watchdog’ов всяких, зависимостей, активаций — красота.

wayland

Не готов, графическая затычка. Альтернатив ксорговым утилкам нема == ненужно. Игорь лагает в усмерть.

Там это, года через 4 вирус разбушуется и политики, готовься.

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

Но зачем мне усложнять себе жизнь, когда я могу сделать то же самое одной командой? Зачем? Ради чего?

а теперь скажи мне, как нам очистить логи для выбранного сервиса (-u)?

Воспользоваться для долговременного хранения логов любым из существующих ранее решений, с которыми journald прекрасно интегрируется. Никакой софт не обязан покрывать все юзкейсы.

или как нам сделать удаленное логирование для этого сервиса?

man systemd-journal-{gatewayd,upload,remote}

да, только по-моему про него писали, что он не предполагает секьюрити и нужен только для теста

Никакие линуксовые контейнеры не предполагают секьюрити. Может OpenVZ разве что.

ну да, NM - это официальный выбор редхат, а networkd - недоделка с проблемами от ЛП. дублированный функционал в рамках одной конторы. Арррхитектура!

Что за херню ты несёшь?

«питоновая лапша» aka NetworkManager

А?

C 95.8%
Makefile 1.0%
Python 0.9%
Meson 0.7%
M4 0.5%
Shell 0.4%
Other 0.7%

(https://github.com/NetworkManager/NetworkManager)

а на серверах сеть не часто переделывают.

Сервера разные бывают.

Нет, потому что мой зюзераутер нужен только мне.

Нет, потому что мой зюзераутер нужен только мне

Пф-ф-ф, у меня роутер на OpenWRT тоже годами не конфигурируется и логи не просматриваются. Там мипс с 64 Мб памяти и systemd тутда в принципе не встанет. Но! Что мне делать с ноутом, с которым я прихожу в незнакомое место и подключаюсь к интернету? Подключаю убс модем? Проектор? Кореш просит раздать ему инет с того же модема? Передать файл по вайфаю? Да, порой проще через инет перекинуть, а порой нет достаточно шустрого инета. Возникают потребности на час, по старинке их нужно было реализовывать правкой текстовых конфигов.

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

Пф-ф-ф, у меня роутер на OpenWRT тоже годами не конфигурируется и логи не просматриваются. Там мипс с 64 Мб памяти и systemd тутда в принципе не встанет. Но! Что мне делать с ноутом, с которым я прихожу в незнакомое место и подключаюсь к интернету? Подключаю убс модем? Проектор? Кореш просит раздать ему инет с того же модема? Передать файл по вайфаю? Да, порой проще через инет перекинуть, а порой нет достаточно шустрого инета. Возникают потребности на час, по старинке их нужно было реализовывать правкой текстовых конфигов.

А как с этим systemd связан-то? С проектором особенно?

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

В том же OpenBSD запросы обычно обрабатываются непривелигерованным процессом.

systemd дал мне единый механизм для запуска своих (и чужих) сервисов на разных дистрибутивах и самое главное их перезапуска после падения. Без изобретения всяких следилок-перезапускалок. Заодно он заботливо собирает то, что сервис в консоль пишет. Таймеры понравились, больше чем cron. И декларативное описание удобней чем shell-скрипты.

Никакой софт не обязан покрывать все юзкейсы.

зачем мне усложнять себе жизнь

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

я об этом и говорю. старый подход позволял решить любую задачу.

или как нам сделать удаленное логирование для этого сервиса?

man systemd-journal-{gatewayd,upload,remote}

kirk_johnson, скажи еще раз человеку, почему вы это не используете.

Что за херню ты несёшь?

ну да, NM - это официальный выбор редхат, а networkd - недоделка с проблемами от ЛП. дублированный функционал в рамках одной конторы. Арррхитектура!

работал

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

Ну уж нет, твой срач, ты и выкручивайся.

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

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

Да не факт на самом деле. Возможно они сразу целились в minimal viable system.

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

Естественно. На ушах стоять он тоже не может.

Я конкретно утверждаю, что невозможность задавать retention по произвольным правилам — это небольшая цена за возможности, которые появляются при использовании journald.

я об этом и говорю. старый подход позволял решить любую задачу.

«Позволять решить любую задачу» никому не упёрлось. Это не самоцель.

«Позволять решить любую задачу» никому не упёрлось. Это не самоцель.

вот в этом наша с тобой основная разница. в понимании профессии, я полагаю.

вот в этом наша с тобой основная разница. в понимании профессии

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

Ну если CUPS + SAMBA говносфт, то я даже не знаю как назвать средний десктопный линуксовый проект…

говнодистр?

изначально решали проблему параллельного запуска

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

Параллельный запуск уже больше 10 лет есть даже в sysvinit. Так что у коллеги видимо какие-то не те представления о причинах появления systemd.

Да всё 💩

Ну если Ubuntu от Canonical 💩, в которой Upstart от Canonical, то тогда всё это то самое 💩

какие проблемы у вас решили эти замечательные вещи

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

С вайландом и миром как-то не сталкивался - на серверах их все равно нет, на десктопе у меня все пока с хоргом работает.

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

Я ж написал - систумд и другие велоиниты. Апстарт один из них

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

Хорошо, слив засчитан.

А как с этим systemd связан-то? С проектором особенно?

А что будет делать тот же udev? Да, вполне возможно, запустит какой-то рукописный костыль. Но если ты хочешь какое-то гттовое решение из коробки, как это есть в маке и винде, то ты будешь делать какую-то более-менее стандартную систему. Да, может быть это не будет частью systemd (мне вообще не нравится их стремление всё совать в один комок), но, тем не менее, какие-то координирующая службы/служба нужна.

В том же OpenBSD запросы обычно обрабатываются непривелигерованным процессом

Может быть OpenBSD особенное или я отстал от жизни, но почему-то мне запомнилось, что на моей убунте было кучу рутовых процессов.

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

Справедливости ради нужно отметить, что s6 делает примерно то же. Все камни в адрес systemd летят от того, что он пытается делать намного, намного больше, чем просто запуск-пеерзапуск. И вот у тебя уже монстр в роли PID 1 процесса, наддежность которого стоит под сомнением даже при условии тщательнейшей протестированности.

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

А разве daemontools/runit не раньше systemd появились и не пытались решить ту же проблему?

А что будет делать тот же udev?

Эээ… Нотифицирует твой композитор вейланда/иксы? Чувак, видео ввод/вывод к systemd не имеет никакого отношения.

Раньше, но их же писал не солнцеликий поцтеринг

Нотифицирует твой композитор вейланда/иксы? Чувак, видео ввод/вывод к systemd не имеет никакого отношения

Я не спорю с этим. Я спорю с тем, что конфигурировать систему не лету никому не нужно.

Я не спорю с этим. Я спорю с тем, что конфигурировать систему не лету никому не нужно.

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

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

Меня тоже смущает, что systemd дофига на себя берет. Но с точки зрения администрирования жизнь он заметно упростил, по сравнению с зоопарком shell-скриптов.

Хотя существует более лаконичная MIPS (ARM и т.д., впишите нужную по вкусу)

На армах квалкома тоже нашли подобную уязвимость. Это неизбежное следствие усложнения системы. На самом деле ошибок и уязвимостей в процессорах очень много, и spectre/meltdown стали лишь наиболее известными.

Меня тоже смущает, что systemd дофига на себя берет. Но с точки зрения администрирования жизнь он заметно упростил, по сравнению с зоопарком shell-скриптов

Вот именно, «по сравнению с зоопарком скриптов». Который не является единственным сопосбом администрирования, но почему-то стал самым распространенным.

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

Под «зоопарком» я имел ввиду, не саму идею SysV, а то что в разных дистрибутивах оно по разному реализуется. Есть же задачи, где несколько дистрибутивов применяются.

Это лень и отсутствие ресурсов у мелких команд, да да, даже деб и те мелочь нищая, а вовсе «не почему-то»

Блин, ну скрипты/конфиги для всего деба не какая-то кучка из десятка кодероадминов делает, правильно? Или, может, им для systemd юниты не нужно было писать?

Под «зоопарком» я имел ввиду, не саму идею SysV, а то что в разных дистрибутивах оно по разному реализуется

Какую еще «идею SysV» ты имеешь в виду? Скрипты rc*.d или их запускалку? Так-то и upstart может запускать эти скрипты.

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

Просто нет смысла сравнивать systemd с sysv.

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

Почему не могут? Коррупция? Вроде же много лет мир линя был полярностью дебиана и редхата, нет?

И вот у тебя уже монстр в роли PID 1 процесса, наддежность которого стоит под сомнением даже при условии тщательнейшей протестированности.

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

Был да весь кончился, оказывается за энтузиазм не платят (: сюрприз, правда? А идейные люди почти вымерли

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

Хорошо, слив засчитан.

все бы на лоре были такими покладистыми и шелковистыми, как ты:)

Скрипты rc*.d или их запускалку?

И то, и другое.

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

нет смысла сравнивать systemd с sysv

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

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

У них разный scope. SysV это просто стартовалка сервисов. systemd это системный менеджер, где есть вообще сеть, дата, контейнеры, шина для сообщений и девайс менеджер.