> Я никого строить не собираюсь, время само выпилит мамонтов в пользу млекопитающих.Мамонты - тоже млекопитающие ;) Кто кого еще выпилит.
> Я уже на себе ощутил его. С апстартом. То что раньше я делал за 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 / разве что?
В случае нормального мониторинга: "То, что настроит локальный админ". Это может быть и очистка логов, и остановка каких-то сервисов.