>>>> Берите скрипт ssh init скрипт из Debian и показывайте как переписать его.
>>> Чьто, внезапно пример с ntp некорректен? А почему?
>> Вы не поняли? Вот почему: "Error 503 Service Unavailable".
>
>error 503? у ntpd? Брысь обратно в свою параллельную вселенную.Нет, тупица. У цитированного сайта генты. Он был недоступен, причем оба раза - когда я отвечал.
> Предпочитаю оперировать фактами. Извините. Вот факты — https://bugs.freedesktop.org/buglist.cgi?product=systemd&com...
Это _известные_ баги. И покуда systemd никому (кроме федоры) нафиг не упал.
А факты Вам - пожалуйста. Берем init-скрипты Debian, шерстим там на предмет всевозможных бинарников, идем в багтрекер и смотрим на количество багов в этих бинарниках. Шаг второй: идем на родные странички проектов и добавляем баги из upstream. Не забывайте в "Closed" состоянии добавить.
Можете смело ограничиться ошибками работы с памятью. Если Поттеринг не волшебный суперасс - почему у него в коде багов на эту тему будет меньше, чем в сопоставимой по размеру базе C кода?
> байткод повторяющихся кусков, из которых оные г-носкрипты состоят чуть менее, чем полностью.
"Не читал, но осуждаю" (с) Приведите "повторяющиеся куски" и их отношение к уникальным на конкретном примере init-скриптов - раз. Два - объясните, почему их нельзя закешировать.
>> На том, что код шелл-скриптов Вы учли весь. А эти ExecStartPre/Post - будут указывать как раз на куски старых init-файлов, грубо говоря.
>
> Ну не обязательно же. Зачем всю дорогу передёргивать? systemd в этих местах делает самый обычный exec(). что в нём — забота maintainerа.
Но разве не Вы хвалились, что _все_ в каждом скрипте из /etc/init.d/* будет сведено к паре строк в конфиге systemd. Ну так вот - не будет, для мало-мальски сложного сервиса. Примеры я приводил. Так что скрипты в ExecStartPre/Post - извольте учитывать.
>>>> Взамен получена туча строк на C, причем используемых только в одном месте...
>>> а) вероятнее всего, не в одном б) машинного кода, вообще-то
>> а) Невероятно. Иначе - соответствующий код вынесли бы в библиотеки.
>
> Исходники доступны, доказывайте.
Пожалуйста. Смотрите на пакет в Debian - никаких либ из исходников systemd не собирается, кроме интерфейсов для взаимодействия с ним (libsystemd-daemon0, libsystemd-login0). Там даже на 5% не наберется. Все остальное - systemd-only.
>> b) в первую очередь - это строки C кода. Со всеми прелестями разработки на этом низкоуровневом языке.
> это C-то низкоуровневый? Это вы ещё на асме и машкодах не писали.
Да. C - низкоуровневый язык. "Переносимый ассемблер". На чем я не писал - можешь дальше фантазировать.
>> Смотрю в /etc/init.d/* - покажите, пожалуйста, пальцем "г-носкрипт". Эти скрипты - ровно никуда не денутся. Шаблонная часть вида case "$1" start) ... stop) - может быть уложена в одну строчку и без systemd. Рассказать как?
> start-stop-daemon?
start-stop-daemon, да. Но он и без того там есть. Просто при желании можно достаточно стандартный кусок "case $1 start) ... stop) ..." c вызовами start-stop-daemon - оформить как функцию. И просто ее вызывать. Будет строчка или две - в духе ExecStart & Description. Просто кто-то понимает, что смысла в подобном рукоблудстве нуль - а кто-то нет.
>> А все остальное - никуда не денется. Любой сложный сервис (апач, постфикс) - потребует ExecStartPre/Post и Ваших нелюбимых "г-носкриптов" там.
> которые внезапно запросто можно реализовать в виде маленьких элегантных бинарников. ну или г-носкриптов — на любителя.
Да. _Можно_. Но делать никто не будет. Останутся скрипты - как и было. Люди не любят экономить на спичках в ущерб своему удобству.
Так и запишем: "Shell-free bootup" - полная лажа. Ничего подобного systemd, вообще говоря, не обеспечивает. Кроме специализированных/игрушечных ситуаций. Кстати, при желании - подобное может и sysvinit. man inittab
>> Что Вы вкладываете в это понятие? Это пресс-релиз какой-то, а не техническое задание. Расшифруйте. *Как* запускать? Что при этом делать, а что - не делать и оставить для других утилит.
> То есть на sysvinit ТЗ не нужно, а на systemd — обязательно, так?
Для sysvinit давно уже есть стандарты (см. man, спецификации LSB) и стабильная реализация.
>> Как выставление всяческих rlimit-ов, приоритетов IO-шедулера и проч. относится к старту сервиса? Вот, появятся у linux новые крутилки ресурсов - Леннарт добавит параметр в соответствующую секцию? И так - до бесконечности?
> То есть как в initскрипте прописать ionice — так нормально и правильно, а как systemd сказать, чтобы выставил нужный приоритет — так ненужно и нерелевантно. Двоемыслие во все поля, да.
"Прописать в init-скрипте" - никак не относится к функционалу init. Есть утилиты или интерфейсы ядра типа /sys - можно "прописать". Появятся новые крутилки в ядре - init никак не изменится. А что будет с systemd? Не вижу двоемыслия - есть банальная неопределенность в том, какие задачи будет решать systemd и какие _не будет_. Имеем bloatware by design.
>> Где граница того, что "архитектор" этой приблуды скажет "хватит - делаем exec shell-скрипта и пусть там админ сам вызывает утилиты для настройки соответствующих параметров".
> Это можно делать уже сейчас — sh -c в любом из Exec*'ов. А Леннарту (я убеждён) вообще пофиг, как это используется.
Вот и я про то, что ему "пофиг". Эта "фича" крутая - давай прикрутим. Вот на таком уровне все "проектирование".
> Беглый гуглёж не нашёл спеки на sysvinit. Двойные стандарты во все поля.
Если Вы "гуглите" man-страницы или LSB - мне Вас жаль...
>>>>> Отдельным бонусом идёт старт сервиса не при загрузке, а при первом стуке в сокет.
>>>> В чем именно бонус - в экономии на спичках? Сисадмин узнает, что с sshd что-то не так (конфиг кривой, к примеру) - не на этапе загрузки, а когда кто-то залогиниться попытается. Зашибись.
>>> а) Что-то мешает отладить конфиг обычным порядком и потом переключить в режим ondemand?
>> А что мешает потом его поломать?
>
> Напомните-ка, зачем-зачем нужно ломать то, что работает?
Затем, что люди делают ошибки. Например - могут ошибиться при очередном изменении конфигурации демона.
>>> б) Во-вторых, это отличное решение для реализации диагностической консоли в каком-нить встраиваемом девайсе.
>> Это в первую очередь - "отличное решение", чтобы получить проблему не в четко известное время (при старте сервисов), а хрен знает когда.
>
> Тестируется на раз. Поэтому мимо.
Это как? При любом рестарте - лезть сразу на сервис, только чтобы убедиться в его работоспособности? Нет другого способа - испорченный конфиг только один источник проблемы при последующем старте on-demand.... В чем тогда смысл "фичи"?
>> Поймите, я не просто ругаю. Мне непонятно - абсолютно-ли необходима эта "фича" Вашей "запускалке для сервисов". Может, лучше ее было бы выкинуть - а сервис, который потребует такого счастья запускать через специальную обертку?
> Эта фича — просто приятный бонус. Не более.
И таких вагон. Грамотно спроектированное системное приложение - имеет четко очерченный функционал. Без всяких "бонусов", приятных или нет.
>> Из документации systemd.service - не очевидно. Ткните, где четко сказано про такое умолчание. Буду рад, если ошибся.
> Элементарно — http://cgit.freedesktop.org/systemd/tree/man/systemd.service... Нашлось за 5 минут.
Клоун, я уже упомянул этот документ: "из документации systemd.service - не очевидно". Покажите мне где там очевидным образом указаны умолчания для Restart. Эта директива вообще - опциональна или нет? Какие вообще директивы в описании сервиса _не опциональны_?
И сравните с форматом inittab для контраста. В последнем - явно указано, что поле action _не является_ опциональным. И, в частности, respawn там должен быть прописан явно.
> Но не выносится. Чуть менее, чем везде — https://gist.github.com/6af2f58c87cd97e1ec08
Потому что люди не видят в этом проблему.
>> А вот остальной "boilerplate" - повторяется как раз не в каждом скрипте. И ровно никуда в systemd - не денется - он просто перекочует в ExecStartPre/Post.
> Это решать maintainerу, systemd тут ничего не навязывает. Хотя я бы предпочёл маленькие бинарнички.
Мда, тяжелый случай. Сколько Вам лет, если не секрет? :) Сможете ответить на этот вопрос честно?
Вы действительно так и не поняли, с учетом всех моих объяснений и примеров, почему эти "маленькие бинарничики" - не появятся _никогда_?
>> Откуда число 100500? "От фонаря" ведь - никаких реальных цифр у Вас нет.
> Предположение, да. Бенчить лень.
>> Объясняйте, конечно. Может появятся таки цифры от Вас - а может кому-то "объяснение" даст повод улыбнуться ;)
> Да вы и сами добудете эти цифры. Года через три.
Ну, вот и кончен разговор про "машинный код" и прочую лабуду от Вас. Кстати, "года через три" - будет wheezy и в планах там даже отдаленно systemd не значится. Не все какашки поттеринга суют куда не попадя...
> Теперь вы показываете, как userspace грузится за аналогичное время, но на sysvinit. Вот тогда мы и похохочем.
У меня десктоп грузится за ~< 5 сек (точнее не измерял, т.к. на уровне "на глаз не заметно"). Организуете мне такую же как в статье железку для тестов и оплатите мое время - покажу как и что можно сделать на sysvinit.
