Зачем нужны системы вроде systemd и почему скрипты запуска демонов такие сложные?

systemd - это не линукс. Как и андроид. Ты «не хотел говорить это сам»?

Я много раз сказал, что systemd - это не Unix-way. Но systemd, несомненно, Linux, и это очень печально.

ключевой разработчки иксов - Keith Packard - матерый дебианщик

Эта старая сволочь, оказывается, еще и в техническом комитете Debian состоит и голосовала за systemd. :)

это наследие доса в энтях

Потому что ты не понимаешь (или делаешь вид, что не понимаешь), что в оффтопике autoexec.nt нифига не рулит загрузкой системы, а объясняет досовским программам, где искать привычные им переменные. Т.е. тут нету даже аналогии.

И еще слако-использование как пруф проверки временем :)

Не показательно, я бы сказал на уровне холоворда.
А вот тебе пример нормального запуска сервиса:
http://sources.debian.net/src/apache2/2.4.7-1/debian/apache2.init

ssh попроще будет.

Однако либо функционала для «простого» написания аналогичного юнита отсутствует(с проверками, блекджеком и кастомными целями для выполнения, кроме старт-стоп-рестарта). Либо юнит писал **дак. Либо в вашем арчике(или откуда этот юнит) каждый сам себе пишет юниты.

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

Опа, так у нас простота и лаконичность уже минусом считается?

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

Проверками занимается сам systemd, а кастомные цели выполнения - это не задача системы инициализации (ее задача запустить/перезапустить/остановить). Остальное туда видимо добавлено по принципу «пусть будет», все равно уже простыню скриптов написали чего уж там.

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

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

Теперь по проверкам, я тебе показал живой файл сервиса, там видно что и как проверяется. Какие именно проверки реализует системд автоматически, если мы захотим получить идентичный функционал дебиановскому сервису? Ты можешь написать/показать такой юнит?
Дополнительные команды сервису как реализовать?

Теперь про доказательства - пока что те юниты что ты показал это обычные ничего не умеющие двухкомандные пускалки:
- /usr/sbin/servicename
- killall servicename

С этой точки BSD rc.d и SysV Init трощит в хлам по функциональности этот самый системд

Сервис это нечто большее чем пускалка демона... В крайнем случае так было всегда, и это удобно, когда ты можешь сказать «service udev reload» или там «service VirtualBox setup»

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

Задачи системы инициализации это запуск, остановка, перезапуск и слежение за сервисами. Настройка/установка и дополнительные команды это дело самого приложения и systemd этим не занимается. То, что в класическом ините эти команды были включены в скрипты по запуску как раз и подтверждает тот факт, что старые инит скрипты перестали выполнять свою функцию - вместо того, что бы заниматься тем, что требуется от инита, они стали тянуть с собой кучу специфических для каждого приложения команд, к тому же в каждом дистрибутиве разных. Все-таки инит скрипт в несколько сотен строк это идиотизм - как его дебажить, если что бы его прочитать и разобраться нужна куча времени?

С этой точки BSD rc.d и SysV Init трощит в хлам по функциональности этот самый системд... Сервис это нечто большее чем пускалка демона...

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

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

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

Как же тогда быть с уже существующим функционалом? Вот предположим завтра дебиан перейдет на системд, значит ли это что теперь я не смогу УПРАВЛЯТЬ сервисом посредством системы управления сервисами? Тогда в чем же выгода от перехода на такую систему?