> ВНЕЗАПНО, если мне не хватило фич системы инициализации - вот тогда я из нее и буду звать скрипт-хелпера, который докостылит до нужной кондиции. Но хотелось бы чтобы в 99.9% случаев этого не требовалось.Ну тогда - добро пожаловать в Дахау. Стройте всех разработчиков и читайте им лекцию на тему того, какие действия ихний демон должон сделать при старте и сколько гемороя на С ради этого они должны тащить.
Эффект предсказуем.
> Я не сомневаюсь что можно прошибить все стены своим лбом. Но слегка утомительно костылить все _стандартные_ типовые случаи.
Что в точности вкладывается Вами в понятие "_стандартного_ типового случая"?
> Я вообще апстарт предпочитаю пока. Оно just works. Вот только знаете, когда конфиг на 5 строк писаный за пару минут делает все ето же что раньше делала пачка костылей и подпорок на 5 кило шеллскрипта, а как бонус система стартует вместо полутора минут 20 секунд, я констатирую EPIC WIN.
Делает что? Как выглядит оный для апача?
Кроме того, сколько стартует система - лично меня мало интересует. Этот старт происходит раз в полгода.
> Bash стандартный весит как раз столько. Если не больше.
Кто-ж виноват, что Вы bash используете в init-скриптах?
> Это с хрена ли 1 раз? Он происходит на каждый старт каждого сервиса. Надо запустить 800К бинарь, распарсить скрипт на 2 страницы, отинтерпретировать, и вот тогда... хм... и все это ради того что делается 1 сисколом? А если посчитать сколько раз за это время сискол выполнится и бинарь запустится, обидно не станет?
Для талантливых, повторю: запуск каждого сервиса происходит _один раз_ при старте системы. При остановке - происходит обратный процесс. Это типичный сценарий (все чуть сложнее, есть разные runlevel). А система может работать годами.
И, извините, Вы опять врете. Помимо exec* - Вам может понадобиться приоритеты выставить, лимиты и проч. Так что даже в Вашей радужной сказке - там отнюдь не один сисколл.
>> А в чем, собственно, "геморой"? Ах, я забыл Вам рассказать о
>> том, _какие именно_ есть механизмы... Ну, rlimits, да те же самые cgroups.
>
> Они для начала не решают проблему с мониторингом упавшего сервиса вообще.
Они для этого и не предназначены. Это статические ограничения. Мониторингом занимаются специальные программы.
> Дебианщики вроде как раз на похожий по смыслу апстарт и собирались (а потом может и на systemd).
Вранье. Есть эти пакеты в дистрибутиве. Ничего более. Приоритет extra - nuff said.
>> Постараемся поправить, если он действительно "мутный".
>
>Что, вот прямо так во всех пакетах? 8-\ А вы какой пакет майнтайните в дебиане? Насчет всех и сразу не поверю - там майнтайнеры указаны разные.
Вы, главное, не переживайте. Я не поправлю - сделаете баг и другие поправят. Главное, что Вы блудословие прекратите и приведете пример реальной проблемы.
> Внезапно,
> 1) Я не люблю опаче за общую монструозность. Его скрипты - вполне в духе опача.
Не асилил? Ну вот вам и контингент пользователей systemd...
Такой гибкой архитектуры, как у апача - еще поискать надо.
Что "шеллы пинать" возможность есть - эт хорошо, конечно. Но не лучше ли сразу признать, что никому кроме десктопов эти ноухау нафиг не сдались? Как что-то полезное запустить, не из поделок Песателя - так вон сразу и шеллы приходится...
> В принципе - может. Поэтому неплохо бы еще и простую валидацию в духе monit. Типа сделать соединение по тцп. Отвечает - ок, не отвечает - дыщ, рестарт. В апстарте такого пока еще нет и такое все-таки придется закостылить. В systemd вроде как что-то такое значилось в планах.
Совать такое в аналог init - тупо. Либо получите монстра, там где была простенькая программа с ясным поведением. Либо получите недомониторинг, который при более-менее серьезном применении нужно просто выключить.
> А что еще она должна видеть? Именно это от нее и надо.
Повторяю, "именно это" - надо только сегфолтящимся приблудам для десктопа. Нормальному мониторингу это будет только под ногами мешаться.
> Остается только вопрос нахрен при этом нужен init который ничего не умеет.
Он умеет. Запустить программы в заданном порядке при переходе с уровня на уровень. Очень простой, понятный и логичный функционал. Это unix. Другие программы - делают разные другие полезные вещи.
> Запуск программы по расписанию - по большому счету разновидность запуска программ. Поэтому, если не ошибаюсь, авторы апстарта и/или системд и на кроны зубы точат, что довольно логично :)
Ну, шелл - тоже умеет программы запускать. Его еще нет в планах?
> Да у инита вообще нет задач. И хрен бы с ними с наворотами типа антиддосов, а вот всякие выставления приоритетов, рестарт упавших и взлет в правильный момент времени когда система к этому уже готова - хотелось бы видеть. В инит всего этого нет а в 100500й раз втыкать стандартный костыль - ни разу не прикольно.
Задачи init я Вам уже пару раз описал. Повторяться уже лень.
"Выставления приоритетов" (и многое другое для статического ограничения ресурсов) - делаются в init-скриптах. Один раз. При настройке системы. Это задача администратора. Для того init-скрипты в любом дистрибутиве представляют собой конфигурационные файлы. И upstart/systemd за Вас данную задачу не решит магически.
> Я бы хотел там видеть в том числе и какую-то базовую систему мониторинга живости сервисов которые он же и запускает, чуть больше чем просто отслеживание падения процесса.
Ее настраивать надо. Это _сложно_ и ровно нет никакой возможности настроить подобное автоматически. 99% функционала отключено нафиг по-умолчанию.
> По минимуму хватило бы простой проверки ответа сервиса на порту.
> Чуть получше: уметь посылать заданный набор байтов и проверять что в ответ приехал ожидаемый ответ. Просто сделать, много веса не добавит. А вот в 90% случаев разгрузит человека от работы по рутинному костылингу стандартных проблем.
В 90% процентах - это лишний спам в ящике. Нету телепатии - до эры AI подобные вещи будут настраиваються людьми. Примите это как факт. Вот почему в любом дистрибутиве - есть только _примеры_ для скриптов/конфигурации систем мониторинга.
> Для вас разумны одни дефолты. Для других - другие.
Вот в этом и проблема. Для десктопа манагера Васи - придется точно также отключить по-умолчанию весь вумный "мониторинг", равно как и для сервера "админа" Коли.
Единственный разумный вариант по-умолчанию: если упало - значит что-то не так, пусть админ посмотрит и разберется. Падать - не должно. Сообразите где это умолчание реализовано? ;)
> Ну так апстарт умеет делать не более чем эн рестартов за эм секунд. Если больше - считаем что сервис окончательно одурел
"эм" - это не число. Это буковки. Сколько это в цифирь? Какому сервису какую цифирь выставить? Не получит ли мейнтейнер пакета по мордасам за то, что выставит эти цифирки?
> Нет, я конечно понимаю что можно дойти вплоть до написания юнит-тестов для апача, но это будет слегонца перебор, потому что в конечном итоге сбои в бизнес логике - это уже явно не в компетенции администратора и лечить сие должны програмеры :)))
Речь быле не о юнит-тестах. Апач может быть жив-живехонек, а скриптам отказано в каких-то ресурсах. Причем, проявиться это может не на главной странице, которая из кеша какого-нить достается, а когда клиент веб-магазина насобирает себе корзину и нажмет кнопку "я хочу дать Вам за это бабло"...
