> Я никого строить не собираюсь, время само выпилит мамонтов в пользу млекопитающих.

Мамонты - тоже млекопитающие ;)  Кто кого еще выпилит.

> Я уже на себе ощутил его. С апстартом. То что раньше я делал за 2 часа копания в кривых и глюкавых скриптах писаных какими-то лабухами на коленке да еще с хардкодом имени сервиса и прочих радостей прямо в скрипте в середине оного, теперь делает конфиг на 5-7 строк который набрасывается за 5 минут из первой же нагугленой болванки (можно даже ман не читать, все и так очевидно). С точки зрения администрирования - небо и земля.

Можно пример Вашего "делания", ради чего Вы 2 часа копались?  И бага в дистрибутиве, где Вы "хардкод имени сервиса в середине" заметили.

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

1) Написать init-скрипт - дело на несколько минут.  Обычно любая уважающая себя "прога" содержит один из вариантов такового.
2) Никакого "мониторинга состояния демона" в init-скрипте и не надо.  Почему - уже объяснял.

> Нет, просто открыл для себя nginx и lighttpd и узнал что серверу совсем не обязательно быть 16-ядерным монстром с 128Гб оперативки чтобы выдерживать целую толпу народа.

Апач тут непричем.  Просто кто-то некомпетентен, не удосужившись прочитать его документацию, вместо хавту по говноблогам про установку nginx...

> Кстати верно замечено: у меня нет цели "осилить именно апач и никак иначе". Я совершенно иными целями оперирую. Вот "показ юзеру странички форума" или там "отдача файла", желательно подешевле и пооптимальнее - это да, годная цель.

Хорошая цель.  Вот и узнайте как это умеет делать апач, прежде чем его хаять.  Да, ради этого придется и в его документацию заглянуть.  Познакомиться с тем что представляет собой схема фронтенд+бакенд, в чем ее приемущества, какие mpm удобно где использовать.

Не нужно думать, что 90% нагруженых сайтов (и как минимум - половина на апаче) _не использующих_ nginx (по статистике на сайте автора) - имеют тупоголовых админов.

> Такой жуткой архитектуры и реализации как у апача - еще поискать надо. Получился огромный и тормозной ресурсожоркий переросток

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

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

>>> пока еще нет и такое все-таки придется закостылить.
>>> В systemd вроде как что-то такое значилось в планах.
>> Совать такое в аналог init - тупо.  Либо получите монстра, там
>> где была простенькая программа с ясным поведением.  
>
> И в каком месте тот же monit монстр? По сути это почти инит, только сделанный менее через задницу и куда более соответствующий жизненным реалиям. Остается только вопрос - а нахрен инит место в списке процессов тогда занимает, ась? Бесполезный балласт.

Для задачи _запуска сервисов в заданном порядке_ monit - это монстр.  Тут не нужны произвольные проверки по TCP/UDP, проверки по протоколам прикладного уровня и прочая.  В частности и _необходимость_ для администратора его конфигурации в каждом отдельном случае.

> Нормальные программы имеют свойство быть модульными и допускать внешние компоненты. Тот же monit не такой уж и монструоный в общем то.

Один такой уже "надопускал" внешних компонент в pulseaudio.  Процесс с PID 1 - очень важная программа, работающая с привелегиями администратора и крайне важно держать его функционал в четко определенных рамках, не обвешивая плагинами по-уши.

> Многокилобайтные простыни которые не обеспечивают даже элементарного рестарта сервиса при откровенном его падении - как-то не сильно удобно и требует кучи костылирования.

1) sysvinit это умеет.  man inittab
2) не хотите простого - настройте нормальный мониторинг (в котором "простыни", кстати, как раз пригодятся для рестарта сервиса)

>> Для того init-скрипты в любом дистрибутиве представляют собой
>> конфигурационные файлы.  
> Обычно они являют собой месиво из г-нокода, констант распиханых по всему файлу а порой и имен сервисов захардкоженых где-то в середине скрипта.

Я смотрю в /etc/init.d/ и не вижу особого говнокода.  Конкретно, проблем описанных Вами.  Пожалуйста, прекратите быть голословным.  Инит-скрипты сервисов в Debian - доступны.  Либо Вы приводите пример - либо прекращаете этот словесный понос.

>> И upstart/systemd за Вас данную задачу не решит магически.
>
> Конечно. Что так что сяк мне придется в одном случае писать конфиг, в втором писать или дорабатывать скрипты. Первое получается намного проще и быстрее и потом результат куда приятнее для глаз. Как бонус еще и система быстрее стартует.

Это _для Вас_ "проще и быстрее".  Вы настраиваете для сервиса chroot?  Очищаете дисковый кеш для mod_cache_disk, как делает init-скрипт апача?

Именно подобные вещи - нетривиальны в init-скриптах.  Остальное - при желании можно шаблонизировать.  Просто никто, кроме Вас, свои проблемы в строчках шаблонного кода не измеряет.

>>> Я бы хотел там видеть в том числе и какую-то базовую систему мониторинга живости
>>>сервисов которые он же и запускает, чуть больше чем просто отслеживание падения процесса.
>> Ее настраивать надо.  Это _сложно_ и ровно нет никакой возможности настроить
>> подобное автоматически.  
>
>Да чего там сложного? Самый тривиальный и действенный метод верификации демона сводится к всего 3 кусочкам в конфиге.
>1) Что и куда послать, по какому протоколу, etc.
>2) Что и за какой таймаут должно приехать в ответ.
>
>На основании подобной логики вполне  можно делать вывод о живости типовых сетевых демонов и их работе. Анализ всякой бизнес-логики уже не дело мониторинга, пожалуй.

Т.е. "пациент скорее жив, чем мертв", а работает ли что на самом деле у клиента - не наша забота.  Клиент сам позвонит и вежливо расскажет?

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

> Какой спам? В какой ящике? Кто и зачем будет спамить?

Ваш мониторинг.  При каждом рестарте сервиса, как минимум.  Или волшебная конфигурация по-умолчанию подразумевает, что письма Вы отправите в /dev/null?

> Опять же, настраивать ынтырпрайзный мониторинг чтобы чекать аж почтарь, хытытыпы и какойнить там днс на мелком сервачке - явный оверкилл и подобное вполне мог бы делать и тот кто их запускает. Нехай станет не только запускачем но и супервизором работы, пусть не самым забористым но покрывающим 90-95% простых случаев и осваиваемый за 2 минуты.

А отключать это счастье сколько минут Вы будете, чтобы нормальный мониторинг настроить?

> Что значит - отключать? Включаться он должен только если я изъявил желание чтобы сервис мониторился на живость.

Вроде systemd и upstart уже делают это _по-умолчанию_, нет?

> Падать не должно. Но если это какой-то автомат стоящий в чистом поле за тридевядь земель...

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

> У меня немного другой взгляд на проблему. Фэйл должен быть залогген и я должен бы получить о нем уведомление, но вот караулить постоянно как цербер?

Тогда Вам нужен полноценный мониторинг.  Какой смысл получать уведомления только о _части_ потенциальных проблем?

>> "эм" - это не число.  Это буковки.  Сколько это в цифирь?  
> По вкусу и здравому смыслу.
>> Какому сервису какую цифирь выставить?  
> На усмотрение админа, имхо.

Ну вот видите.  Мониторинг _требует_ конфигурации.  Причем - локального админа.  Мейнтейнеру пакета для сколь-либо сложного сервиса - цифирки расставить, скорее всего, не получится.

>> Не получит ли мейнтейнер пакета по мордасам за то, что выставит эти цифирки?
> Не думаю. А за что? В дефолтах все-равно на всех не угодишь, а какие-то прописывать надо.

Отключить нафиг.  Вот такой дефолт и выставят.  Может завершим блудословие и Вы циферки нарисуете?  Вы мейнтейнер пакета nginx.  Че пропишем?  Какой таймаут, как часто и куда ходить?

> Это на грани невозможного (анализ поведения одной программой другой произвольной программы). Как бы вы ни изгалялись, а такой шанс останется всегда.

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

> И в любом случае это уже не компетенция запускалки

Вот именно.  Итак, что произойдет с "функционалом мониторинга" этой запускалки - его отключат ради нормального.  Ну и нафига он тогда нужен?  Пусть запускалка - запускает и больше под ногами не мешается.  Это и делает sysvinit.

> если у вас скажем место закончилось и не удается лог записать, то сколько ни перезапускай сервис, ничего не изменится. Что монитор может сделать? rm -rf / разве что?

В случае нормального мониторинга: "То, что настроит локальный админ".  Это может быть и очистка логов, и остановка каких-то сервисов.