Переход Ubuntu на Systemd

[Bizdelnick]

Покажите, пожалуйста, хоть одно мнение члена Технического комитета Debian о том, что следует оставить только systemd.

I think a substantial degredation of functionality when running on an init
system other than the Linux default would be okay for for jessie+1.

https://bugs.debian.org/cgi-bin/bugreport.c...bug=727708#3453
Дальше искать вломы.

[alv]

Значит есть и причины для распространения. Модой на него можно было бы объяснить fedora, opensuse, но не debian.

Причины разные
fedora и opensuse - всё та же политика: с первой всё ясно, Suse, с тех пор как перестала быть европейской, вынуждена играть с RH на его поле и тянуться за ним (вспоминаем GNOME в SLE, хотя европейская Suse всегда была столпом KDE
Arch и прочие дистры второго эшелона - вот тут мода
плюс фактор возраста
разработчики их - молодые пацаны, которые искренне могут верить, что всё новое - это хорошее и прогрессивное
плюс для большинства майнтайнеров это одной заботой меньше: не надо поддерживать собственные схемы инициализации, фюрер за всех всё придумает
с Debian'ом сложнее
но для всех примкнувших главный фактор - боязнь опоздать к раздаче слонов: через несколько лет wayland, gnome и, вероятно, kde без systemd просто не будут работать
вот в этом я и вижу главный вред от systemd'а: в сущности, это евгенический эксперимент по разделению FOSS на два мира
а это и есть начало конца

а Поттеринг... он тут вообще ни при чём
если бы Поттеринга не было, его бы выдумали
ну звался бы он Джоном Томпсоном или Махатмой Джавахарлаловичем...
ничего бы от этого не изменилось

[den_beckett]

Я вот не заметил тут поттерофанов (кто-то говорил, что он велик, и святость его несомненна?).

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

Я вижу лишь тех, кому нравится конкретное ПО, systemd, PulseAudio.

Вот беда-то. А мне, может, firebird нравится, но я не агитирую за него в интернетах, и не пропагандирую замену им mysql и sqlite, с неприменным прибиванием гвоздями. Я им просто пользуюсь.

А антипоттерофаны как раз заметны (виноват во всех бедах мира).

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

Хотя Поттеринг не в одиночку пишет эти продукты и в другие дистры их не протаскивает. Но виноват всё равно он, так?

Только ему это не говори - обидиццо. Судя по высказываниям, ЧСВ у него зашкаливает.

Не нравится systemd? Ну и что? Используйте те дистры, где есть альтернатива. Все переходят на systemd? Так может есть для того причина?

Ну какбэ в тотальной слежке за гражданами тоже есть причины. Однако почему-то откровения того же Сноудена нехилую бучу вызвали. Видишь ли, все взрослые люди понимают, что "демократия" - это сказка, но все-таки не любят, когда их совсем за баранов держат. Я помню, как все в Арче начиналось. На юзверей и их мнение просто поклали с прибором. Я тогда же дебианщиков предупреждал, что у них также будет - на меня столько грязи вылили. Типа Дебиан не Арч и там такого не может быть, потому что не может быть никогда. Однако прошел всего год с хвостиком, и что мы видим? Да тоже самое - собрались свои ребята и "чиста конкретно" за всех порешали.

Но не один RHEL его ведь использует. Значит есть и причины для распространения.

Ога - весь rpm-based ынтырпрайз на него перешел. Потому что тупо таскают из шапки с федоркой спеки - самим пилить лень.

Модой на него можно было бы объяснить fedora, opensuse, но не debian.

Дебианцы никак не могут скинуть с телеги гнум. Вспомни историю о том, как xfce хотели сделать ДЕ по умолчанию. И вот тут действительно есть объективные причины - гнум в качестве ынтырпрайзного окружения никатит ну никак. Однако гнумовское лобби оказалось сильнее голоса разума. Вся проблема Дебиана в том что у него нет лидера, который либо протолкнул бы своим авторитетом непопулярные решения, либо выгнал бы пятую колонну на мороз.

[Hephaestus]

Потому что иначе его мнение не имеет ценности, ибо непроверяема (а значит, сомнительна, с учётом наличия обоснованных аргументов оппонирующей стороны) его правдивость, а согласие или несогласие с ним превращается из рациональной процедуры проверки аргументов в иррациональный вопрос веры.

Его мнение - это всего лишь мнение. Имеет право на существование. Так же как моё или Ваше, или Леннарта.


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

И как тут проверять правдивость? Где тут обоснованные аргументы? Здесь обе стороны абсолютно равноправны, ибо и то, и другое - именно мнение, ИМХО, если угодно. Не больше и не меньше.

Но зуб даю, что вы его объяснения не читали, как не читали и подробную и обширную пользовательскую документацию, ибо "нинужно" - но вместо этого предпочли составить своё мнение на основе сообщения какого-то пользователя LOR.

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

Что по поводу прочитанного могу сказать...
Проект серьёзный, Поттеринг с компанией вложили много труда,
коллектив там, наверняка большой, народу много,
работа проделана большая.
У меня лично сомнений нет: это дело так не пойдет.

У данного проекта есть ряд полезных качеств - такие полезные мелочи типа замера времени загрузки в разрезе сервисов. Но это именно мелочи, не более того. В целом - это огромный, сложный и совершенно бесполезный монстр. Ибо его достоинства - это его недостатки.
Простой пример. Основная идея - заменить init-скрипты на service-файлы, которые не являются скриптами, а являются лишь конфигурационными файлами. И обрабатываются централизованно.
Казалось бы, что в этом плохого? Несомненно, это - достоинство новой системы. И одновременно - серьёзный недостаток. Почему?
Очень просто: Скрипт может не запуститься из-за ошибки. И страдает, в общем случае, только этот скрипт. Ну и программа, запускаемая этим скриптом. И такая ошибка поддаётся исправлению.
Ошибка в коде systemd приводит к тому, что страдают все сервисы - отдельных скриптов нет, а только файлы с настройками. И исправлять это значительно сложнее, ибо написано на С, содержит много обобщений и требует компиляции.
Сам же Леннарт в статье сетует, что приходится добавлять в код много всяких "если" да "кабы".
Очевидно, что это - потенциальный источник множества ошибок.

Ещё один пример, уже из личных соображений.
У меня настроена демонизация торрент-клиента.
Я создал по шаблону init-файл, модифицировал его под свои нужды, создал необходимые файлы настроек и т.п.
Сначала я использовал screen, потом, по прошествии времени, стал использовать dtach, переход от одного к другому не составил никаких проблем, кроме того, я имею возможность сам определить параметры, имена, права и прочее.
Как такое реализовать в контексте systemd - ума не приложу. Если и удастся обеспечить запуск программы, то всё равно не будет той гибкости, которую мне даёт шелл-скрипт, ибо там я - хозяин, как решу, так и будет, а здесь за меня пытается решать systemd.

Если такую штуку внедрить в дистр - это будет уже не дистрибутив linux, а дистрибутив systemd, образно говоря, и уж точно это будет не unix-way. Это будет совсем другая система (не будем показывать пальцем), в которой от Linux останется только ядро.

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

Особенно позабавило вот это:

Spoiler

Автор пишет о службах и процессах

В этой статье мы рассмотрим две простых команды, которые позволят вам наглядно оценить схему взаимоотношений systemd и порожденных им процессов. Первая из этих команд — все та же ps, однако на этот раз в ее параметры добавлено указание выводить сведения по контрольным группам, а также другую интересную информацию:

Код: Выделить всё

$ ps xawf -eo pid,user,cgroup,args

.....

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

Код: Выделить всё

alias psc=’ps xawf -eo pid,user,cgroup,args’

.....

Альтернативный способ получить ту же информацию — воспользоваться утилитой systemd-cgls, входящей в комплект поставки systemd. Она отображает иерархию контрольных групп в виде псевдографической диаграммы-дерева
.....

Как видно из листинга, данная команда наглядно показывает принадлежность процессов к их контрольным группам, а следовательно, и к службам, так как systemd именует группы в соответствии с названиями служб.

Казалось бы, всё в пользу systemd - он(она, оно?) решает поставленную задачу в рамках единой системы.
Однако ниже по тексту в разделе FAQ видим следующее:

Вопрос: Как узнать, какой службе принадлежат вот эти процессы?
Ответ: Для этого можно воспользоваться командой ps

Код: Выделить всё

$ alias psc=’ps xawf -eo pid,user,cgroup,args’
$ psc
PID USER
CGROUP
...
COMMAND

или просто посмотреть /proc/$PID/cgroup.

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

Осторожно, не сломайте себе руки.

Не распарсил. Это Вы о чём?

Это применимо вообще к любым новым решениям. Это не повод не тестировать и не использовать их.

Вот пусть Леннарт с компанией и тестирует. И использует. В той же Федоре.
А я не хочу это тестировать, понимаете? Не хочу и всё.

И неплохо бы обойтись вот без этого цирка:

Spoiler

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

В будущем мы намерены аккуратно форсировать процесс перехода на новые конфигурационные файлы: поддержка старых файлов будет удалена из systemd.

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

Помогите нам стандартизировать Linux! Используйте новые конфигурационные файлы! Поддерживайте их в апстриме, поддерживайте их во всех дистрибутивах!

Типа: Вот ребята, мы создали фичастую штуку, давайте быстро все перестраивайтесь под нас.

Да? А с какой стати?

[alv]

Ибо я прочитал вот это

Кстати, очень примечательный документ.
Длинный, подробный.
Ни по sysV, ни по BSD Init ничего подобного не, подозреваю, что нет и по Upstart
А почему нет?
Потому что ни sysV, ни тем более BSD Init не нуждаются в таком документе для понимания их.

Вдумчиво читал где-то до половины

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

[Bizdelnick]

Ога - весь rpm-based ынтырпрайз на него перешел. Потому что тупо таскают из шапки с федоркой спеки - самим пилить лень.

Справедливости ради - суся не таскает. У них спеки (точнее, политики, в соответствии с которыми они пишутся) намного более грамотные, чем в федоре с шапкой.

[Hephaestus]

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

Вы имеете в виду вот это?

Spoiler

Две консоли играют особую роль: tty1 и tty6. tty1, при загрузке в графическом
режиме, используется для запуска дисплейного менеджера, а при загрузке в многополь-
зовательском текстовом режиме, systemd принудительно запускает на ней экземпляр
getty, не дожидаясь переключений57 .
Что касается tty6, то она используется исключительно для автоматического запус-
ка getty, и недоступна другим подсистемам, в частности, графическому серверу58 . Мы
сделали так специально, чтобы гарантировать возможность входа в систему в текстовом
режиме, даже если графический сервер займет более пяти консолей.

[Rootlexx]

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

И как тут проверять правдивость?

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

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

Неверно. Не упрощайте систему инициализации до абсурда. Скрипты ощутимо сложнее, чем кажутся, и весьма значительную часть кода они делят между собой: практически в каждом есть такая строка:

Код: Выделить всё

. /lib/lsb/init-functions

Кроме того, происходит вызов большого количества внешних программ, ошибки в которых также возможны.
Как в случае sysvinit, так и в случае systemd основным способом борьбы с ошибками является тщательное тестирование перед выпуском.

У меня настроена демонизация торрент-клиента.
Я создал по шаблону init-файл, модифицировал его под свои нужды, создал необходимые файлы настроек и т.п.
Сначала я использовал screen, потом, по прошествии времени, стал использовать dtach, переход от одного к другому не составил никаких проблем, кроме того, я имею возможность сам определить параметры, имена, права и прочее.
Как такое реализовать в контексте systemd - ума не приложу. Если и удастся обеспечить запуск программы, то всё равно не будет той гибкости, которую мне даёт шелл-скрипт, ибо там я - хозяин, как решу, так и будет, а здесь за меня пытается решать systemd.

Не понимаю, что вам мешает вызов тех же команд что с использованием screen, что с dtach поместить в сервис-файл. Если очень хочется, можно и скрипт (состоящий лишь из нужных команд, а не подобие init-скрипта) запускать. Только вам не придётся беспокоиться о PID-файлах, корректном завершении и так далее.

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

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

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

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

Особенно позабавило вот это:

Автор пишет о службах и процессах

В этой статье мы рассмотрим две простых команды, которые позволят вам наглядно оценить схему взаимоотношений systemd и порожденных им процессов. Первая из этих команд — все та же ps, однако на этот раз в ее параметры добавлено указание выводить сведения по контрольным группам, а также другую интересную информацию:

Код: Выделить всё

$ ps xawf -eo pid,user,cgroup,args

.....

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

Код: Выделить всё

alias psc=’ps xawf -eo pid,user,cgroup,args’

.....

Альтернативный способ получить ту же информацию — воспользоваться утилитой systemd-cgls, входящей в комплект поставки systemd. Она отображает иерархию контрольных групп в виде псевдографической диаграммы-дерева
.....

Как видно из листинга, данная команда наглядно показывает принадлежность процессов к их контрольным группам, а следовательно, и к службам, так как systemd именует группы в соответствии с названиями служб.

Казалось бы, всё в пользу systemd - он(она, оно?) решает поставленную задачу в рамках единой системы.
Однако ниже по тексту в разделе FAQ видим следующее:

Вопрос: Как узнать, какой службе принадлежат вот эти процессы?
Ответ: Для этого можно воспользоваться командой ps

Код: Выделить всё

$ alias psc=’ps xawf -eo pid,user,cgroup,args’
$ psc
PID USER
CGROUP
...
COMMAND

или просто посмотреть /proc/$PID/cgroup.

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

Избирательное цитирование. В тексте:

или просто посмотреть /proc/$PID/cgroup. Также см. главу 2.

А я не хочу это тестировать, понимаете? Не хочу и всё.

http://www.communitywiki.org/cw/DoOcracy

[alv]

Вы имеете в виду вот это?

Это самое. Точно Леннарту надо было или в религиозные пророки подаваться, или в политагитаторы: зарывает парень такой талантище в землю.
PS возможно, он и программёр великий - не копенгаген судить.
Но что на иных поприщах сравнялся бы с с самим дедушкой Лениным - медицинский факт. А то и (страшно сказать) превзошёл бы...

[Rootlexx]

И неплохо бы обойтись вот без этого цирка:

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

В будущем мы намерены аккуратно форсировать процесс перехода на новые конфигурационные файлы: поддержка старых файлов будет удалена из systemd.

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

Помогите нам стандартизировать Linux! Используйте новые конфигурационные файлы! Поддерживайте их в апстриме, поддерживайте их во всех дистрибутивах!

Типа: Вот ребята, мы создали фичастую штуку, давайте быстро все перестраивайтесь под нас.

Да? А с какой стати?

И в каком же месте здесь вы увидели требование "давать быстро перестраиваться под них"? Лично я вижу лишь убеждение, призыв, а следовать ему или нет, дело ваше.
Кроме того, присутствуют избирательное цитирование вне контекста (ваше) и небольшие неточности перевода (автора). В оригинале:

It is our definite intention to convince you to use these new configuration files in your configuration tools: if your configuration frontend writes these files instead of the old ones, it automatically becomes more portable between Linux distributions, and you are helping standardizing Linux. This makes things simpler to understand and more obvious for users and administrators. Of course, right now, only systemd-based distributions read these files, but that already covers all important distributions in one way or another, except for one. And it's a bit of a chicken-and-egg problem: a standard becomes a standard by being used. In order to gently push everybody to standardize on these files we also want to make clear that sooner or later we plan to drop the fallback support for the old configuration files from systemd. That means adoption of this new scheme can happen slowly and piece by piece. But the final goal of only having one set of configuration files must be clear.

Перевод выделенного куска:

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

Ну и наконец: какое отношение личность Леннарта Поттеринга, его манера высказываний, его поведение и так далее - имеет отношение к технической дискуссии? Давайте обойдёмся без аргументов в стиле ad hominem.

Кстати, очень примечательный документ.
Длинный, подробный.
Ни по sysV, ни по BSD Init ничего подобного не, подозреваю, что нет и по Upstart

http://upstart.ubuntu.com/cookbook/

А почему нет?
Потому что ни sysV, ни тем более BSD Init не нуждаются в таком документе для понимания их.

Ну да, зато нуждается в таком документе.

[alv]

какое отношение личность Леннарта Поттеринга, его манера высказываний, его поведение и так далее - имеет отношение к технической дискуссии?

А где Вы увидели техническую дискуссию? С первого момента появления systemd её продвижение ведётся методами политической пропаганды или религиозной проповеди.
А сам Поттеринг, как я неоднократно говорил, тут действительно ни при чём.

Ну да, зато нуждается в таком документе.

Ничего подобного. Если не совать башизмы куда надо или куда не надо.
Потому что это документ совсем из другой библиотеки. Не из районной, а из ГПНТБ

[serzh-z]

Rootlexx
Ты тратишь слишком много энергии, расслабься уже, тут собрались поттерненавистники, которые ненавидят Поттера, но уже сами забыли за что и не могут это объяснить. =) Наверное просто потому, что человеку всегда нужно кого-нибудь ненавидеть. Лучше их убедить, что они ненавидят его и его поделухи правильно. =)

[Rootlexx]

Ну да, зато нуждается в таком документе.

Ничего подобного. Если не совать башизмы куда надо или куда не надо.

Ничего подобного. Знать shell нужно всё равно, хотя бы в его POSIX-подмножестве. Кроме того, надо знать многие не вполне очевидные вещи [1] [2].
В любом случае скрипт - это полноценная программа, которая притворяется конфигурационным файлом. Это даёт большую гибкость, но и большую сложность и больший простор для ошибок.

[drBatty]

В любом случае скрипт - это полноценная программа, которая притворяется конфигурационным файлом.

это уже зависит от администратора и майнтейнера. В sh конечно можно напихать что угодно, но вопрос — а надо-ли? Мне так ваш systemd напоминает лечение головной боли путём отрубания головы.

PS: мимокрокодил, так мысли вслух.

вот кстати с соседнего форума: http://linuxforum.ru/viewtopic.php?id=33970

символизирует:

что я сделал этими командами?

[alv]

Знать shell нужно всё равно, хотя бы в его POSIX-подмножестве

некоторое представление о шелле нужно иметь - это много для чего пригодится, не только для понимания скриптов инициализации
знать systemd нужно только для понимания systemd'а
разницу улавливаете?

скрипт - это полноценная программа, которая притворяется конфигурационным файлом.

а вот это уже издержки конкретных реализаций sysV
в BSD Init скрипты от конфигов отделены чётко
как и в тех дистрах Линукса, которые использовали BSD-подобную схему, сейчас, кажется, только CRUX и остался

UPD кстати, одна из причин любви дистроителей к systemd: если используешь свою модификацию sysV (а практически в каждом дистре она своя, да - хотя до сих пор это никому не мешало) - то тебя же и будут поминать добрым ласковым словом, если чего напортачил
а если systemd - можно всё на Поттеринга валить, тем более что он об этом и не узнает.

[Bizdelnick]

скрипт - это полноценная программа, которая притворяется конфигурационным файлом.

а вот это уже издержки конкретных реализаций sysV
в BSD Init скрипты от конфигов отделены чётко
как и в тех дистрах Линукса, которые использовали BSD-подобную схему, сейчас, кажется, только CRUX и остался

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

[alv]

тут собрались поттерненавистники

во! узнаю подход:
я хороший и люблю Поттеринга (дедушку Ленина, советскую власть, родину - нужное дописать)
значит, те, кто ему не молятся - плохие и его ненавидят
успокойтесь, Сергей: Поттеринг не стоит ненависти, по моему мнению - это просто пешка в не очень большой игре, которая могла бы зваться Васей Джонсоном или Томом Сун Линем
и это Вам много раз говорили открытым текстом на этих страницах
Вам же требуется создать образ врага - Поттеро-ненавистника
что свидетельствует о чём? - правильно

[alv]

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

разница в том, что в BSD Init смешать конфиги и скрипты нельзя - по крайней мере, я не видел умельца, который бы это делал
а в sysV перемешать их в принципе можно
но это не значит, что нужно, и тем более обязательно
я когда развлекался собиранием Линукса от самого от Скратча, смотрел, как народ в этом деле упражняется
кстати, там много хороших примеров того, как можно сделать плохо

[Hephaestus]

В сообщении, на которые вы ссылаетесь, даже подтверждающих ссылок не было.

Повторяю в очередной раз: это было мнение, ИМХО. С каких пор ИМХО нуждается в подтверждающих ссылках?

Как в случае sysvinit, так и в случае systemd основным способом борьбы с ошибками является тщательное тестирование перед выпуском.

Правильно, беда однако в том, что ошибку в shell-скрипте я могу исправить сам (и исправлял) без каких-либо затрат.
Ошибку в коде systemd так просто не исправишь, хотя бы потому, что потребуется правка исходников и перекомпиляция. Мне одного этого достаточно, чтобы не связываться с systemd.

Не понимаю, что вам мешает вызов тех же команд что с использованием screen, что с dtach поместить в сервис-файл.

Ну, например, я могу задать имя пользователя, под которым стартует скрипт, имя сокета, права доступа, каталоги и т.д.
В статьях Поттеринга в описании сервис-файлов я не увидел таких возможностей. тех возможностей для сервис-файлов, которые мне были бы нужны. Может они и запрятаны где-то глубже, но это уже копать надо.
К тому же сам Поттеринг говорит:

Конечно, отнюдь не все init-скрипты так же легко преобразовать в service-файлы.
Но, к счастью, «проблемных» скриптов не так уж и много.

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

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

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

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

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

Избирательное цитирование. В тексте:

или просто посмотреть /proc/$PID/cgroup. Также см. главу 2.

Ничего подобного. Я нашёл оригинал статьи. Там этот FAQ вообще отсутствует.
Следовательно, оригинальный FAQ находится где-то в другом месте, отдельно от статьи. И вряд ли содержит сслыку на главу 2, ибо никак не связан со статьёй.

http://www.communitywiki.org/cw/DoOcracy

Не понял. Что это такое?
Потрудитесь изложить своими словами. Не уподобляйтесь богословам (они очень любят ссылками разговаривать).

[Hephaestus]

И в каком же месте здесь вы увидели требование "давать быстро перестраиваться под них"?

Ну, если уж на то пошло, в каком месте моего поста я говорил про требование? Где Вы увидели у меня слово "требование"?

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

Правда что ль? Ну, это мы ещё посмотрим, поддаётся ли systemd бесследному выпиливанию или нет.
А если Вы намекаете, что всегда можно перебраться на другой дистр - так это я и без Вас знаю. И говорил как раз об этом в начале дискуссии.

Кроме того, присутствуют избирательное цитирование вне контекста (ваше) и небольшие неточности перевода (автора).

Насчет (не)точностей перевода спорить не буду, а насчет избирательного цитирования - не согласен.
Как его ни цитируй - systemd лучше не становится.

Ну и наконец: какое отношение личность Леннарта Поттеринга, его манера высказываний, его поведение и так далее - имеет отношение к технической дискуссии? Давайте обойдёмся без аргументов в стиле ad hominem.

Я про личность Леннарта ни слова не сказал. Мне его личность вообще по барабану.

[Hephaestus]

Не знаю, что из себя представляет BSD-подобная схема

Ну если совсем коротко: в BSD имеется один большой файл, где расписаны уровни и из которого запускаются скрипты.
В противовес SysV, где на каждый уровень - свой каталог со ссылками на скрипты.

[alv]

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

не совсем так
во-первых, в BSD нет уровней, есть два режима, single и multi, не считая старта, рестарта и шатдауна
есть главнй исполняемый скрипт - /etc/rc, есть главный конфиг - /etc/rc.conf, из которого тот получает параметры
правится (при необходимости) конфиг, скрипт трогать необходимости обычно нет
кстати, на самое святое (и самое уродское) порождение sysV - на runlevel'ы в systemd не поягнули, ограничились их переименованием и накручиванием турусов на колёсах

[NickLion]

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

Не шлангую (что бы это слово не значило). Именно, что никаких поттерингофанов.

Вот беда-то. А мне, может, firebird нравится, но я не агитирую за него в интернетах, и не пропагандирую замену им mysql и sqlite, с неприменным прибиванием гвоздями. Я им просто пользуюсь.

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

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

Ещё раз, обращайтесь с этими вопросами к разработчикам гнома, которые гвоздями прибивают.

Только ему это не говори - обидиццо. Судя по высказываниям, ЧСВ у него зашкаливает.

Да, возможно так, ибо его ответы не всегда кажутся адекватными.

Однако прошел всего год с хвостиком, и что мы видим? Да тоже самое - собрались свои ребята и "чиста конкретно" за всех порешали.

Мантейнеры дистрибутиво всегда решают за всех. Они его делают. Так что да, они и решения принимают. Не нравится — форкайтесь. Это всегда было в дистрибутивах линукса. Разве нет?

Ога - весь rpm-based ынтырпрайз на него перешел. Потому что тупо таскают из шапки с федоркой спеки - самим пилить лень.

Как уже говорили, openSUSE взяли RPM, но сильно его переделали. И структура пакетов отличается.

Дебианцы никак не могут скинуть с телеги гнум. Вспомни историю о том, как xfce хотели сделать ДЕ по умолчанию. И вот тут действительно есть объективные причины - гнум в качестве ынтырпрайзного окружения никатит ну никак. Однако гнумовское лобби оказалось сильнее голоса разума. Вся проблема Дебиана в том что у него нет лидера, который либо протолкнул бы своим авторитетом непопулярные решения, либо выгнал бы пятую колонну на мороз.

А вот гном — там вообще странные решения — прибивать гвоздями к systemd, linux, ЧСВ выше крыши сделать из гнома отдельную ось. Я бы его выкинул. Но вот вопрос, было бы ли меньше недовольных?

[Rootlexx]

некоторое представление о шелле нужно иметь - это много для чего пригодится, не только для понимания скриптов инициализации
знать systemd нужно только для понимания systemd'а
разницу улавливаете?

Так я говорю о том, что для корректного написания скриптов нужно знать много тонкостей и встречающихся подводных камней, понимание которых при обычном использовании командной строки практически не требуется. Кроме того, нужно знать и грань между POSIX и не-POSIX, ибо в повседневном использовании встречается либо bash либо zsh, повседневная работа в которых функциональным подмножеством POSIX не ограничивается.

Повторяю в очередной раз: это было мнение, ИМХО. С каких пор ИМХО нуждается в подтверждающих ссылках?

Ровно с тех пор, как вы принимаете или используете его как аргумент. Не нужно рассчитывать, что можно вывалить своё или чужое мнение на техническом форуме в технической дискуссии, и при этом избежать требований его обоснования. Информационный шум обычно не приветствуется, ибо бесполезен.
Кроме того, утверждения вида "функции на тысячи строк" - это уже не ИМХО, ибо не являются личным мнением.

Правильно, беда однако в том, что ошибку в shell-скрипте я могу исправить сам (и исправлял) без каких-либо затрат.
Ошибку в коде systemd так просто не исправишь, хотя бы потому, что потребуется правка исходников и перекомпиляция. Мне одного этого достаточно, чтобы не связываться с systemd.

Исправите ошубку в, скажем, GNU head, использующемся в скрипте, без правки исходников и перекомпиляции? Не забывайте, что встроенная функциональность POSIX-оболочки довольна бедна, и в основном используются внешние команды, которые являются такими же скомпилированными бинарными файлами.

Ну, например, я могу задать имя пользователя, под которым стартует скрипт, имя сокета, права доступа, каталоги и т.д.

Имя пользователя, естественно, в сервис-файле задаётся. Остальное прошу пояснить, что имеется в виду.

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

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

Не просто возможность, а необходимость. Автоматически проблемы не решаются. Необходимо вмешательство человека.

См. выше.

[Rootlexx]

Ничего подобного. Я нашёл оригинал статьи. Там этот FAQ вообще отсутствует.
Следовательно, оригинальный FAQ находится где-то в другом месте, отдельно от статьи. И вряд ли содержит сслыку на главу 2, ибо никак не связан со статьёй.

Сюрприз:

Or you can even check /proc/$PID/cgroup directly. Also see this blog story.

http://www.communitywiki.org/cw/DoOcracy

Не понял. Что это такое?
Потрудитесь изложить своими словами. Не уподобляйтесь богословам (они очень любят ссылками разговаривать).

Чтение вслух с выражением - за отдельную плату.

Ну, если уж на то пошло, в каком месте моего поста я говорил про требование? Где Вы увидели у меня слово "требование"?

давайте быстро все перестраивайтесь под нас

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

[drBatty]

Исправите ошубку в, скажем, GNU head, использующемся в скрипте, без правки исходников и перекомпиляции? Не забывайте, что встроенная функциональность POSIX-оболочки довольна бедна, и в основном используются внешние команды, которые являются такими же скомпилированными бинарными файлами.

ох... Ну это уже совсем плохо. Пойти на вас пожаловаться что-ли? Ну неужели непонятно, что
1. возможностей оболочки (в т.ч. POSIX) вполне достаточно для функционала init, и зачем там head мне лично непонятно.
2. код всяких head вылизан и протестирован десятилетиями, и если уж там и есть баги, то нужно быть уж очень неадекватным, и придумать нечто ТАКОЕ, чего никто до вас не делал.

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

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

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

вот тут нужен временный костыль. И очевидное решение: shell-скрипт. Или я не прав опять? Ну поправьте меня, зачем нужен постоянный подымльщик для временных решений?

[Rootlexx]

код всяких head вылизан и протестирован десятилетиями, и если уж там и есть баги, то нужно быть уж очень неадекватным, и придумать нечто ТАКОЕ, чего никто до вас не делал.

А вы почитайте багтрекер coreutils. Я сам там недавно небольшую ошибку исправил, как раз в head.

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

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

Я там выше привёл две ссылки для примера, когда недостаточное понимание принципов работы оболочки привело к ошибкам.

вот тут нужен временный костыль. И очевидное решение: shell-скрипт. Или я не прав опять? Ну поправьте меня, зачем нужен постоянный подымльщик для временных решений?

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

[Hephaestus]

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

Можно подумать, для написания корректного сишного кода, знаний нужно меньше.

Ровно с тех пор, как вы принимаете или используете его как аргумент. Не нужно рассчитывать, что можно вывалить своё или чужое мнение на техническом форуме в технической дискуссии, и при этом избежать требований его обоснования. Информационный шум обычно не приветствуется, ибо бесполезен.
Кроме того, утверждения вида "функции на тысячи строк" - это уже не ИМХО, ибо не являются личным мнением.

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

Исправите ошубку в, скажем, GNU head, использующемся в скрипте, без правки исходников и перекомпиляции?

Ошибка в скрипте, использующем GNU head и ошибка в самом GNU head - это две разные ошибки.
Первую из них я исправлю. Почему я должен исправлять вторую - непонятно.

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

Ошибки в коде программ - да, согласен. Ошибки в шелл-скриптах - напротив, вполне в компетенции админа и успешно исправляются.

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

Ну и как здесь поможет автоматический перезапуск? Ошибка в БД автоматически исчезнет?
Или автоматический перезапуск составит за админа отчет? Или может быть автоматический перезапуск умеет патчить и собирать пакеты? Какую из перечисленных вами функций админа обеспечит автоматический перезапуск упавшего демона?

Чтение вслух с выражением - за отдельную плату.

В таком случае, ходите по своим ссылкам сами.
Делать мне больше нечего, только угадывать, на что Вы там намекаете.

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

Ну, так слова Леннарта, процитированные мной, тоже воспринимаются вполне однозначно.
Посему Ваша претензия выглядит странно.

[Rootlexx]

Можно подумать, для написания корректного сишного кода, знаний нужно меньше.

При чём здесь код на C? Пройдите по ветке субдискуссии вверх.

Ну и как здесь поможет автоматический перезапуск? Ошибка в БД автоматически исчезнет?
Или автоматический перезапуск составит за админа отчет? Или может быть автоматический перезапуск умеет патчить и собирать пакеты? Какую из перечисленных вами функций админа обеспечит автоматический перезапуск упавшего демона?

Задачу минимизации времени простоя.

[Hephaestus]

При чём здесь код на C?

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

Задачу минимизации времени простоя.

Каким образом?
Автоматически поднять упавшее - отличная идея, но кто сказал, что оно вот прям так и поднялось? Упало-то оно не просто от скуки, верно? Причины ведь были? А, стало быть, и не поднимется, пока причины не устранены.
Можно хоть до посинения автоматически перезапускать.