> Старт/стоп сервисов например. Хотя логичнее делать простейший запуск через сисколы вместо дергания на каждий пук шелла.

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

> Тупо пинать шелл на 800к для старта 20к демона если для этого достаточно сделать 1 сискол.

Где Вы видели шелл на 800k?  Даже если и так - это накладные расходы на старт, который один раз происходит, а не ежеминутно.  

> А мне вот нужна нажежная и предсказуемая система без лишнего геморроя.

А в чем, собственно, "геморой"?  Ах, я забыл Вам рассказать о том, _какие именно_ есть механизмы...  Ну, rlimits, да те же самые cgroups.

Учиться надо, вот оно в чем проблема-то.

> Да, только вот там простыни мутного кода на 2 страницы делают то же самое что в нормальной системе инициализации делает конфиг на 5-7 строк. И даже меньше.

Покажите этот мутный код в Debian, пожалуйста.  Постараемся поправить, если он действительно "мутный".  А вот "то же самое за 5 строг" - фиг сделаете.  Откройте, пожалуйста, инит-скрипт apache2 и расскажите как реализовать тамошнюю логику на 5 строк.

> 1) Init не поставит сервису нужный приоритет по простому.

Для этого и есть скрипты.  Ставьте, пожалуйста.  Хоть для процесса сервера - хоть для всех процессов из сценария.

> 2) А если нам надо запустить сетевой демон не раньше чем законектится вон тот сетевой и-фейс

Для этого есть порядок последовательности запуска скриптов.  И давно есть зависимости в заголовке LSB-совместимого сценария, чтобы все это было просто настроить.

> 3) Кому как не запускалке виднее всех что сервис внезапно нае..лся когда его не просили об этом?!

"Запускалке" видно только то, что процесс с данным PID - умер.  Или что больше в этой cgroups нету процессов.  Увы, сервис может быть запросто в состоянии "нае...лся" и при этом не сегфолтиться и не завершаться.

И сценарии решения этой проблемы могут быть сложнее "убить и перезапустить" - вот почему и есть monit.  Возможно, нужно логи почистить, возможно запуститить какой-то анти-ddos скрипт.  Или - отладчик подключить.  Все это - не задачи для простой пускалки сервисов init.

> 4) А вот если сервису стало ну совсем плохо, не надо перезапускать его 100 раз в секунду, чтобы не создавать сильную нагрузку на хост тупым рестартом без перспектив! Если сервис не взлетел за несколько попыток - забить на это (+админу выслать сообшение о проблемах в идеале).

Вот и я написал о том, что "не надо".  Только и "забить" - не обязательно лучшее решение.  Еще парочку я набросал выше.  Поймите одно: Единственно Верной (тм) политики разрешения таких проблем - нет и быть не может.  Это задача для гибко конфигурируемой системы мониторинга (monit), а не для init и любой его альтернативы.

> Да вообще-то, если современный запускач реализован _нормально_, делая ВСЕ что от него надо, monit должен стать всего лишь костылем с повторным функционалом. Monit решает вполне стандартные проблемы администрежки. Они настолько типовые что почти все из этого списка по уму должен уметь сам init. Или на кой он нужен если ничего не умеет?

sysv init умеет: стартовать сервисы в нужной (определяемой их зависимостями) последовательности.  Все.  Вы хотите из init сделать систему мониторинга?  Она должна поддерживать тесты кучи протоколов, да еще и настраиваться автомагически?  Накой тащить функционал, единственной разумной настройкой по-умолчанию которого будет - "отключить нафиг".

Поймите, что нет универсального способа настроить ПО типа monit.  Например, действие по-умолчанию для apache может быть "перезапустить n раз и потом забить" - толку от ПО с таким умением будет 0, исключая сегфолтящиеся поделки Поттеринга.  Нормальный тест сервиса должен включать проверку работы бизнес-логики приложения, возможно с оглядкой на другие процессы или ресурсы в системе.