Зачем? Я не пытаюсь доказать, что они там нужны. Я пишу, что в случае с инитскриптами они возможны. И кроме mysql есть и ещё появится много других сервисов. Если потребуется какая-то специфическая проверка - значит надо систему инициализации дорабатывать, да? В случае с инитскриптами получаем язык программирования, которым можно сделать всё, что нужно.

Вот тебе ман по системд: http://www.freedesktop.org/software/systemd/man/systemd.service.html

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

Так же есть Exec**** для всех событий, которые могут происходить с сервисом.

наглядных скриптов

Простой пример:
http://pastebin.com/2KWY7zx6 (/etc/init.d/mysql из дебиана, обычный LSB-совместимый скрипт, рассчитанный на sysvinit)
http://pastebin.com/MjM37CtM (/lib/systemd/system/mysqld.service из федоры, конфиг для systemd)
Суди сам.

И Убунтушный Upstart: http://paste.kde.org/724280/

franchukroman> вот в файле для systemd без них разобраться было бы гораздо проще, чем в инитскрипте.

Там и без комментариев ясно, где прописан путь к mysql и его конфигу. Собственно, для этого комментариев там и нет. Так что твоё утверждение очень спорное.

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

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

Таким, что для юникса нехарактерно такое ядро.

Ядро Minix - вообще микро. Ядро DragonFlyBSD — гибридное.

То бишь, QNX при таком раскладе - тоже UNIX? ;)

Unix-like. SuS она не реализует.

pekmop1024> systemd ненавидят только те, кто когда-то давно с кровью и потом осилил баш-скриптинг, и то не в совершенстве, а на грани школьника, и теперь не в состоянии разобраться в чем-то новом.

Ты заляпал экран моего нетбука жиром...

Да. ВНЕЗАПНО модули systemd нельзя использовать вне systemd.

Вот! Я об этом же и толкую! Я вижу, ты соглашаешься со мной, что systemd написал полный кретин :)

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

Внимание! Вопрос! А нафига столько опций для юнита, когда можно сделать стандартными средствами на шелле и быстро, который итак знают?

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

Ты вообще понимаешь, о чём речь?

Вот upstart как раз таки наименее наглядный.

А нафига C, когда есть ассемблер?

Потому, что так гораздо проще и нагляднее.

в случае нестандартной ситуации придётся дописывать сам systemd. В случае с инитскриптом достаточно только внутри него нужную функциональность доделать и не надо ничего с инитом вытворять и подвергать риску внесения багов.

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

kernelpanic> В нестандартной ситуации пишется отдельный service-файл, в котором вытворяешь все, что тебе заблагорассудится.

То бишь, часть того, что обычно находится в инитскрипте, придётся отдельно реализовывать и компилировать что-ли?

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

Я то понимаю, а вот ты хочешь чего-то странного.

инит скрипты довольно сложны

Ты в 5 строчках запутаться можешь? У меня для тебя плохие новости.

Я уже дважды разбирался с инит скриптами

А я часто с ними имею дело.

часть того, что обычно находится в инитскрипте, придётся отдельно реализовывать и компилировать что-ли?

Ну если у тебя совсем уж нестандартная ситуация, то можно и поконпелировать, а вообще и shell-скриптом обойтись можно.

Кстати. Мне больше всего уход от init скриптов понравился тем что не нужно больше пользоваться всякими костылями вроде start-stop-daemon. Upstart сам отслеживает запущенный процесс и выполнит его остановку если поступит соответствующая команда.

Вот upstart как раз таки наименее наглядный.

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

Модули включаются и выключаются на этапе сборки.

Это не модули, а кучка левых утилиток (типа hostnamed) и второстепенных фич, которым вообще не место в systemd. Реальной модульностью в systemd даже не пахнет.

Всё, что может быть отключаемо - отключаемо

Т.е. создать dev-файл для только что подключённой флешки (udev) без запущенного демона журналирования (причём именно без journald) — задача технически невыполнимая? :)

То бишь, часть того, что обычно находится в инитскрипте, придётся отдельно реализовывать и компилировать что-ли?

В случае если тебе не хватит функционала systemd ты всегда можешь из service файла вызвать внешний bash скрипт который сделает тебе ЗБС. но это насколько редко бывает.

выдыхай бобер

А я часто с ними имею дело.

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

Вместо наглядных скриптов навязывается непрозрачная система

Это как раз наоборот, один из плюсов systemd.

Суди сам.

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

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

без перекомпиляции половины системы инициализации

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

Этим «плюсом» обладает абсолютно любая технология.

Вам в палате мер и весов, эталоном жирности работать только.

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

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

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

Там достаточно возможностей для реализации практически любых костылей. Без никаких перекомпиляций.

Давай расскажи о ситуации, когда потребуется "перекомпиляция половины системы инициализации".

наглядных скриптов
bash

И часто это у вас бывает, голубчик?

Боюсь, квалификации аникейщика недостаточно чтобы понять недостатки негибкой системы и возможные осложнения с ней.

Давай расскажи о ситуации, когда потребуется «перекомпиляция половины системы инициализации».

Пример: хочу запускать setfont со своими волшебными параметрами.

Мсье, отмотайте топик на первую страницу, там приведен вполне убедительный пример наглядного скрипта. Особо пикантно, что приводился он как негативный пример.

Арч на systemd переехал уже давно.

Да да. Тут остановить запуск DM никак не получается, но виновата в этом видимо не кривость systemd, а «изменения, неожиданности, разрыв контекста».

Частные случаи helloworld'ов не считаются.

mysql - это хелловорд? А в нашей вселенной это СУБД. Раскажите, как там у вас, что считается сложным софтом?

В случае если тебе не хватит функционала systemd ты всегда можешь из service файла вызвать внешний bash скрипт который сделает тебе ЗБС. но это насколько редко бывает.

В случае, если нужен типовой скрипт, скелет выносится в отдельный файл, а потом импортируется.

А где будут лежать bash-скрипты для юнитов? В /etc/init.d/? :)

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

Конкретнее. С какими параметрами? Давай точную задачу, легко решаемую init-скриптами, но нерешаемую без перекомпиляции systemd.

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

Ты можешь различить сложность запускающего скрипта и сложность самой софтины?

В чём трудность переучивания на systemd то? Я даже слово «переучиваться» сюда как-то применять стесняюсь...

Обычно они таки пропорциональны. Так приведи пример сложного скрипта уже, не томи.

дай угадаю... ты прочитал ту статью и теперь можешь сформулировать свою нелюбовь к systemd, правильно?

Это вполне типовая задача, по-твоим критериям сложности весь SysV Init - сплошные хелловорды. Приведи пример Ъ-энтерпрайз скрипта инициализации.

Зайди в свой init.d и посмотри же, ну.

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

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

Лично я не люблю systemd по одной простой причине - монолит и фиг на ходу изменишь.

теперь можешь сформулировать свою нелюбовь к systemd, правильно?

Да!!! Наконец-то смутно ощущаемое стало понятным!!! Я такое облегчение почуствовал, что просто кончил!!!

да пользователю ведь вообще плевать, что там под капотом?

Тогда с чего бы мнение пользователя что-то значило?