>> Не понимаю аргумента с худшими проблемами.
> Да сколько угодно. Меньшая прозрачность системы, сложность отладки и т.п.Прозрачность init-скриптов в дистрибутивах вызывает у меня сомнения. Особенно, если учесть что я не гуру вообще, и в sh в частности. Ключик запуска я конечно поменять смогу, но дебри юнитов или init-скриптов в случае более комплексной проблемы я не полезу, а скорее задам вопрос знающим людям.
>> Я прочитал это и сделал вывод что таки телепатический модуль вкрутили:
>> that one request. Also, dependencies between services no longer have to
>> be configured to allow proper parallelized start-up: starting all sockets at
>> once and a service needing another, it surely can connect to its socket."
> Главное, забыть что существуют разные способы IPC...
Главное не забыть, что мы говорим о сервисе и его клиентах. Между сервисом и клиентом трудно представить более подходящий тип IPC, чем сокет. Остальные IPC, такие как shared memory и семафоры(есть еще что-то в linux, что я забыл?) как правило используются внутри сервиса, зависимостей снаружи нет. А оставшиеся pipes, socket, message queue - systemd поддерживает. Думаю, это покрывает подавляющее большинство сервисов, если не все.
>> То есть как я понял, стартуем все сервисы зараз, а они потом
>> сами разберуться. Может чего недопонял, хз.
>Ну да. Помимо сервисов есть еще всякие fsck, quotaon и проч. - для чего сокетов, увы, уже не хватает. В общем, Before=, After=, WantedBy=, etc - наверно какие-то враги народа придумали, а автор непричем.
Да, к сожалению не все сервисы можно стартануть независимо. Однако то, что в конфигурации запуска некоторых сервисов зависимости можно не указывать - положительный фактор, который уменьшает сложность поддержки системы в целом.
>> d-bus всего лишь небольшой демон. не самый быстрый, но один, если не
>> единственный, из удобных способов одному процессу сказать чего-нибудь другому всем понятным
>> способом.
>Это называется ICP. И существует *много* разных методов оного. И было. Задолго до всяких DBUS...
Думаю, просто не стали изобретать велосипед и просто взяли готовую библиотеку, упрощающую IPC. То, что в sysvinit используется свой протокол, а не dbus сути не меняет. К тому же есть возможность собрать dbus довольно аскетичным способом, который сведет возможность появления дырки в безопасности по вине dbus к минимуму.
>> Причем тут роль, которую выполняет компьютер? не знаю, чем может
>> помешать d-bus, даже на сервере.
> Бесполезностью. Лишними проблемами с безопасностью.
Если на сервере стоит systemd, то dbus не бесполезен. Насчет безопасности выше.
>> Хорошая привычка проверять конфиги после внесения изменений. Большинство серьёзных программ
>> это умеет делать априори.
>sshd - не умеет. Его нужно *попросить* это сделать (но вы, напоминаю, после редактирования это забыли). И с поломанным конфигом он не запустится. Точно так же и nginx, и apache, и еще 100500 используемых сервисов. Все, короче.
Нет, не всё. Во первых, вы сами привели примеры тех демонов, для которых on-demand активация довольно странное решение, и, во вторых, есть проверка конфигов. В третьих, если вы админите удалённый сервер, то вы _должны_ проверять конфиги, тем более в таких критичных сервисах как sshd. Иначе вы ссзб. И systemd тут ни при чём, sysvinit никак вас не спасёт. И в случае с sysvinit, и с systemd после перезагрузки с неверным конфигом вы получаете нерабочий сервис. Отличие только в том, что с systemd(или (x)inetd кстати) вы узнаете об этом при первой попытке использования. Например, на удалённой машине в случае c sshd равносильно фейлу независимо от системы инициализации.
>> Вы приводите пример, что не надо забывать о других ролях системы, кроме
>> десктопа. С другой стороны, я могу сказать тоже самое. Вас никто
>> не принуждает использовать on-demand и dbus, просто такая возможность есть.
> Эта возможность откручивается полностью? Т.е. весь код для поддержки этого брахла?
systemd - это в первую очередь система инициализации, в основе которой лежит активация как принцип, неважно принудительная, on-demand, socket-based, mount-based и т.д. И вы спрашиваете можно ли отключить то, ради чего все городилось и лежит в основе systemd. Но таки вы можете это не использовать, если вам будет спокойней. А запретить dbus - это то же самое что запретить sysvinit использовать pipe.
>>> Это вам автор пообещал. А мы скажем мягше - пытается не ломать. Не всегда получается...
>> Ну дык, работа над ошибками, как и ошибки, будут всегда..
> Ну вот когда *таких* ошибок не будет вовсе - можно подумать и о включении в дистрибутивы.
Пока не будет пользователей - не будет ошибок. Release often, release early? Ну а право включать что-то в дистрибутив или не включать - оставьте его мантейнерам. Если они это сделали - у них были на то причины. А у вас как всегда остается выбор - уйти на другой дистрибутив или заняться поддержкой initscripts на текущем.
>>> Ну-ну. Багтрекеры дистрибутивов посмотрите...
>> не ковырялся.
> Вот-вот...
По логике тут должна быть ссылка. Жду.
>>>> Слизанный синтаксис. Там, где по-уму нужен нормальный скриптовый язык - пихают порнографию с ConditionPathExists и прочим недо-тьюринговым брахлом.
>>> У декларативного синтаксиса есть плюс - он лучше поддаётся разбору компом и
>>> вообще автоматизации. Довольно важная фишка.
>> Что-то имеет смысл разбирать - что-то нет. Для того, что имеет - придуманы, к примеру, LSB-заголовки в init-скриптах. systemd вообще написан на C там, где у людей раньше был shell. Так что "разбирается" в каком-то смысле - не лучше...
>> С другой стороны, это немногим отличается от if [ -d "path" ] ))
> Ну-ну. Тогда подождите когда гуру поймет, что ему циклы понадобились...
Тогда будьте добры, в доказательство своих слов, приведите пример, когда цикл(да и вообще скрипт со сложной логикой) при старте сервиса необходим. Я не смог придумать. К тому же, вам никто не мешает сделать unit для своего сложного скрипта и в нем стоять хоть на ушах.
>> Я думаю сложность преувеличена. Типичный юнит для systemd это несколько строк говорящего
>> самого за себя текста.
> Ну-ну. Вам то же задание, что и прочим "фанатам". Есть init-скрипт апача в Debian. Перепишите все для systemd с сохранением совместимости - время пошло.
Давайте обойдёмся без ярлыков. Я не являюсь фанатом, я лишь пытаюсь понять причины ненависти к systemd. А домашние задания оставьте при себе. Или выполните его сами, чтобы до конца проникнуться отвращением к systemd и накопить аргументы )
>> А там, где нужна сложная логика -
>> без манов не обойтись в любом случае, как в случае с
>> systemd, так и в случае с sysvinit.
> Так вот - не нужна. Любой профпригодный администратор знает shell, да и о стандартных системных утилитах вкурсе.
Видимо, профпригодные администраторы всосали manы по шеллу и стандартным утилитам с молоком матери?
>>> Для этого разработчику всегда было достаточно написать man-страницу для сервиса, указать его ключи и т.п.
>> Тем не менее многие включают в дистрибутив init-скрипты, особенно если процесс загрузки
>> сервиса неочевиден и имеет ньюансы.
> И что тогда изменится? LSB уже сейчас есть. Включают init-скрипты, а будут - юниты для systemd. "Простота" написания оных - мифическая, как вам указали. А более вы ровно никакой проблемы не решаете. Есть бардак init-скриптов при наличии LSB - будет бардак разных юнитов.
Ничего вы мне не указали. Только общие фразы. Насчет бардака - я не пророк, поэтому в будущее заглядывать не умею. К тому же особого бардака в init-скриптах вроде нет, просто у каждого дистрибутива они отличаются координально, что вносит некий диссонанс. Поживем - увидим. То, что я вижу сейчас - systemd у меня в виртуалке прекрасно обслуживает arch и fedora. С апачем, кстати.
>> Затем же, зачем нужен telinit, просто этот способ более продвинутый.
> telinit уже есть. Таки зачем?
>> Я не владею серверами, и не сталкивался с такими use-case'ами. Могу предположить только
>> одно - если звезды падают, значит это кому-нибудь нужно?
> Т.е. - не знаете, понятно.
Если вам будет легче - используйте telinit. Он работает. Просто есть еще вариант использования, под который я не могу придумать use-case, но это не значит, что его не существует. Попробуйте поискать, если интересно. Навскидку, то что нашел в wiki fedorы, но выглядит довольно натянуто:
"Primarily it has two intended use cases: to allow the user to temporarily enter a specific state such as "Emergency Shell", terminating current services, and provide an easy way to return to the state before, pulling up all services again that got temporarily pulled down."
Лично я telinit пользовался от силы раз 5 за все время работы с линуксом, как правило, когда тупил логин менеджер, не запускался xorg и т.п.
>>>> 9) что плохого в архитектуре systemd, если она расширяема на манер плагинов
>>>А что хорошего? sysvinit расширяется любым языком, и?
>> если так рассуждать, то systemd аналогично расширяется любым языком ))
> Получается излишняя сложность, нет? Если есть и плагины, и возможность запуска сценариев - может что-то лишнее?
Думаю, не весь функционал systemd можно или целесообразно реализовать в рамках сценариев.
