Релиз systemd 257

помечены флагом $

Это про какую страну?

Ну значок доллара - понятно какая страна.

Казалось бы, безобидная новость про опенсурс, а и сюда У политоту приплели.

Свободного от чего?

Поделитесь опытом - судя по его возможностям, это можно использовать как систему централизованного управления конфигурациями?

Нужно, годно, хорошо.

Дежурно напоминаю, что вопящим про неюниксвейность systemd следует обратить свой взор в man inittab, чтобы обнаружить там кейворды wait, once, powerfail и respawn, которые четко показывают, что init задумывался как средство для спауна и слежения за процессами, а баш-лапша была навернута поверх него позже, потому что изначальный init получился слишком дубовым. Так что systemd - это не более чем развитие идей, изначально заложенных в SysV init.

Дежурно напоминаю, что вопящим про неюниксвейность systemd следует обратить свой взор в man inittab

Да. Открывал этот ман в виртуалке с Ubuntu 4.10, ЕМНИП. Про перезапуск демонов с случае аварийного завершения, например, там было написано прямо.

Ну то есть это демон, а не набор скриптов?

Здорово же.

В общем то да. UNIX-way.

вопящим про неюниксвейность systemd следует обратить свой взор в man inittab, чтобы обнаружить там кейворды wait, once, powerfail и respawn, которые четко показывают, что init задумывался как средство для спауна и слежения за процессами

Ну и в чем противоречие? systemd кроме спавна процессов еще лезет настраивать сеть, резолвить адреса, писать журналы и вообще и жнец и швец, вопли то про это. Что там за «инициализация системного времени» в новости, например, почему это делает запускалка сервисов а не сервис управления системным временем?

systemd кроме спавна процессов еще лезет настраивать сеть, резолвить адреса, писать журналы и вообще и жнец и швец

Время идет, мантры хейтеров не меняются

лезет настраивать сеть

Этим занимается networkd.

резолвить адреса

resolved

писать журналы

journald

И так далее. Всё это - отдельные демоны, которые общаются между собой по dbus. Кстати, networkd можно использовать отдельно от systemd и наоборот.

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

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

Ты неправильно думаешь о systemd, как о запускалке сервисов. Это системный менеджер, который отвечает за то, чтобы ОС работала правильно и консистентно: запускает, проверяет, обеспечивает реакцию на события, оповещает о них, и так далее. Init задумывался этим, просто недожали, и в итоге все функции были возложены на портянки шелл-скриптов, что само по себе уже - говно. По недоразумению эти скрипты превратились в полноценные сложные программы, но при этом написаны на уродливом языке с отсутствующей типизацией. Теперь эти авгиевы конюшни приводят в порядок.

Казалось бы: безобидная шутка, но и в ней увидели политоту.

Политоту везде можно увидеть, если очень сильно захотеть.

Так что systemd - это не более чем развитие идей, изначально заложенных в SysV init.

В учебниках по биологии пишут, что человек на 60% состоит из воды. Документация для systemd тоже состоит из воды больше, чем на половину. Значит-ли это, что последний является развитием идей человека и может превращать юниксвей на входе - в кал и мочу на выходе?

Эта глбукомысленная отсылка к биологии — она тут к чему?

В моем программистском детстве вместо доллара на клавиатурах был символ клопа раздавленного (этакий нолик с четырьмя рожками, см. тут — https://habr.com/ru/companies/timeweb/articles/706422/). И в знакогене терминала ДВК и 85ки, кстати, тоже. ВАс это, может быть, порадует :)

SystyemD не управляет конфигурацией, он исполняет имеющуюся.

Сам на эту тему давно думаю, и прихожу к выводу, что нет. Все эти юниты systemd глубоко локальны и попытки их как-то централизовано хранить и заливать мне не известны. Впрочем, к SystemV init это тоже относится. Возможно, для всяких там Ansible и SaltStack что-то и придумали, но мне про это ничего не известно. Вообще, линуксу категорически не хватает средств централизованного управления.

Хотя, в датацентрах это тупо решается клонированием виртуальной машины, что устраняет проблему.

Последняя версия, поддерживающая совместимость с sysvinit скриптами.

Это уже не важно. :)

Всё говно в итоге

Вот было бы логическим продолжением systemD наличием API для такого функционала. Нет ничего плохого в подобном «комбайне», если он решит задачи. Ansible и SaltStack - это вобщем-то тоже API (судя по hh.ru) и они даже стандарты.

Да. На Искре такой же символ был )

Мексику, конечно.

В учебниках по биологии пишут, что человек на 60% состоит из воды.

А твой комментарий состоит из воды на все 100%. По существу есть что возразить?

реализующий IPC varilink.

Этот varlink – это что-то значимое? Или можно спокойно не вникать в очередную проходную технологию?

Релиз

Выпуск.

У нас принято говорить непонятно перед заказчиком. Так больше стоимость

Достигнута очередная вѣха въ разработкѣ свободнаго системнаго распорядителя systemd.

Либо крестик сними, либо трусы надень.

SystyemD не управляет конфигурацией, он исполняет имеющуюся.

Сам на эту тему давно думаю, и прихожу к выводу, что нет. Все эти юниты systemd глубоко локальны и попытки их как-то централизовано хранить и заливать мне не известны. Впрочем, к SystemV init это тоже относится. Возможно, для всяких там Ansible и SaltStack что-то и придумали, но мне про это ничего не известно.

В ансибле есть модули для управлениями юнитами systemd - можете создавать и конфигурировать их как пожелаете.

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

Сам так и делаю - есть плейбук который на виртуалках разворачивает промитиус экспортер и сервис под него. Или гитею на сервере.

Кстати, networkd можно использовать отдельно от systemd и наоборот.

Только зачем?!

Всё это - отдельные демоны, которые общаются между собой по dbus.

Ты неправильно думаешь о systemd, как о запускалке сервисов. Это системный менеджер

Ну так в том и дело, что это такой «пакет приложений». И они там в целом заточены на то чтоб друг с другом работать. Кому-то нравится такой подход, кому-то - нет. Я бы лучше с нуля собрал то что мне нужно чем выковыривать то что не нужно.

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

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

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

Только зачем?!

Что именно зачем? Зачем запускать сервисы или зачем управлять сетью?

Я бы лучше с нуля собрал то что мне нужно

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

чем выковыривать то что не нужно

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

Вкусовщина

Нет. Шелл дает тебе огромное количество возможностей по выстрелу в ногу, причем не только себе, но и коллеге с другой стороны земного шара. Проблема с шелл-скриптами настолько велика, что люди даже изобрели shellcheck, чтобы хоть как-то жить с этим дедовым кулхакерством. Шелл-скрипты надо искоренять, заменяя на нормальные скриптовые языки с типизацией, или вообще бинарный код, как с systemd. Я тебя уверяю, тебе никогда не понадобится залезать в его исходники, если твои юзкейсы не выходят за рамки серверов или десктопов. Даже я с эмбедом туда не лазаю, и systemd у меня прекрасно работает.

каждый со своим форматом конфигов

Большая часть конфигов - обычные INI. Всякие tmpfiles используют собственные построчные форматы для простоты парсинга и дополнения, в том числе фанатами шелл-скриптов. Всё хорошо документировано и описано в соответсвующих манах.

как только задача выходит за рамки «запусти@перезапусти» приходится в это закапываться все

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

И я не разу не сталкивался с проблемами с шелл-скриптами из-за того что это шелл-скрипты.

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

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

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

Системдэ.

«Системнаго» — тоже заимствование из греческого.

Там это, Shepherd 1.0.0 вышел, а вы всё со своим systemd.

Мне нравится, как чел в комментах сам придумал повод для срача и сам теперь активно срач поддерживает. Хотя казалось бы. Релиз минорота, интересных фич не завезли, чо его обсуждать.

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

По сути до Лени Потного начало доходить, что dbus нафиг не нужен для межпроцессного взаимодействия в сустемд. Это после того как всякие бездари типа hateWin с intelfx тут годами затирали, что dbus абсолютно необходим потому что содержит некие супер-пупер фичи, без которых вообще никак и никуда.

ненужно.

бездари типа hateWin с intelfx тут годами затирали

Да-да, мы тупые, а ты гений. Лучше расскажи, что Поттерингу было делать 14 лет назад, когда dbus уже был стандартным IPC в линуксе, а varlink не было и в помине (он был анонсирован только в 2017 году)? Он должен был нагородить свой велосипед просто ради удовлетворения воспаленного чувства прекрасного у всяких там Lrrr?

Да. В 255, емнип, завезли новый механизм спаунинга демонов, вместо связки fork()+exec(). В этом релизе какой-то новый IPC добавили, о котором лично я впервые слышу. Надо разобраться, что это за зверь такой, и в чем вообще его идеология

Кажется, начинает доходить. В качестве транспорта эта хрень использует стандартные TCP или UNIX сокеты. Более того, эта приблуда не нуждается в сервере как таковом, в отличии от dbus; достаточно просто подключить нужную библиотеку и создать сокет. За счет сочетания этих качеств, varlink может быть доступен с самого начала, сразу после загрузки ядра и запуска PID 1, и при этом ему не нужна отдельная ядерная подсистема, как в случае с KDBUS.

А главное, я не пойму, чем ты возмущаешься. Когда в одном из тредов ты заявил о ненужности dbus и о возможности запилить IPC прямо на сокетах, я тебе возразил. Суть моего возражения была в том, что dbus — это готовый, стандартный и обкатанный протокол, а в случае с голыми сокетами тебе придется изобретать свой протокол с нуля. В ответ ты просто назвал меня макакой и свалил. А теперь ты предлагаешь varlink в качестве идеальной замены DBUS, при том, что varlink, — сюрприз, сюрприз! — является тем самым самодельным протоколом поверх сокетов. Не видишь ли ты противоречия в собственных словах?

Полагаю, что это породит больше проблем, чем решит существующие. Непонятно, как аутентифицировать изменения. Такие штуки надо делать только если есть что-то типа linux-домена.

Ansible и SaltStack - это вобщем-то тоже API (судя по hh.ru) и они даже стандарты.

Не совсем так. Это инструменты для выполнения команд (сценариев, программ. whatever) сразу на нескольких целевых системах с возможностью проверить статус исполнения на каждой. А стандартами они стали только в мире девопсов.

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

Нет, тебе скорее etcd надо смотреть в паре с ansible

Да на всех советских копмпах, походу. На ЕС-ке, по моему, тоже. На БЭСМ-6 не помню, совсем зеленый был тогда. И мапился на ASCII 0x24.

Да на всех советских копмпах, походу. На ЕС-ке, по моему, тоже. На БЭСМ-6 не помню, совсем зеленый был тогда. И мапился на ASCII 0x24.

Потому что доллар – это бакс. А бакс – это козёл. А козёл – это такая конструкция:

\ /
 o
/ \

Козёл для пилки дров (проф.: ко́злы).

Чтобы не быть голословным:

• Мой комментарий: systemd 255 (комментарий)

• Ответ Lrrr: systemd 255 (комментарий)

Кроме того, то же самое писал liksys несколькими постами выше:

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