>> Старт/стоп сервисов например. Хотя логичнее делать простейший запуск через сисколы
>> вместо дергания на каждий пук шелла.
> Это гибкое решение. В шелле можно вызвать утилиты, ВНЕЗАПНО, если мне не хватило фич системы инициализации - вот тогда я из нее и буду звать скрипт-хелпера, который докостылит до нужной кондиции. Но хотелось бы чтобы в 99.9% случаев этого не требовалось. А оставшийся 0.1% я так и быть докостылю. Желательно чтобы такое случалось после дождичка в четверг, после того как рак на горе даст 3 зеленых свистка вверх.
> для последующего ограничения процесса.
Я не сомневаюсь что можно прошибить все стены своим лбом. Но слегка утомительно костылить все _стандартные_ типовые случаи. Нахрена мне гибкость резинового фаллоимитатора в случае если я хочу гвоздь забить? Молоток должен быть удобным и должен хорошо забивать гвозди. А то что его в узел видите ли нельзя завязать - может и хрен с ним?!
> И не ждать, покуда наш Песатель соизволит к systemd прикрутить соответствующие
> крутилки или сам сервис получит соответствующие ключи для командной строки...
Я вообще апстарт предпочитаю пока. Оно just works. Вот только знаете, когда конфиг на 5 строк писаный за пару минут делает все ето же что раньше делала пачка костылей и подпорок на 5 кило шеллскрипта, а как бонус система стартует вместо полутора минут 20 секунд, я констатирую EPIC WIN.
>> Тупо пинать шелл на 800к для старта 20к демона если для этого достаточно сделать 1 сискол.
> Где Вы видели шелл на 800k?
Bash стандартный весит как раз столько. Если не больше.
> Даже если и так - это накладные расходы на старт, который один раз происходит,
Это с хрена ли 1 раз? Он происходит на каждый старт каждого сервиса. Надо запустить 800К бинарь, распарсить скрипт на 2 страницы, отинтерпретировать, и вот тогда... хм... и все это ради того что делается 1 сисколом? А если посчитать сколько раз за это время сискол выполнится и бинарь запустится, обидно не станет?
> а не ежеминутно.
А это уже зависит от природы сервисов.
>> А мне вот нужна нажежная и предсказуемая система без лишнего геморроя.
> А в чем, собственно, "геморой"? Ах, я забыл Вам рассказать о
> том, _какие именно_ есть механизмы... Ну, rlimits, да те же самые cgroups.
Они для начала не решают проблему с мониторингом упавшего сервиса вообще. Они скорее дополняют картину. Кстати поттеринг вроде как и cgroups грозился прикрутить. Вообще, логично - если уж фичи есть прямо в ядре, стартер имеет полное право пинать виртуалки и контейнеры, очевидно. Стартить их откуда-то сбоку при старте системы? Хм, опять костыли... на задачи которые опять же уже стали типовыми. Знаете, типовые сценарии пользования системой все-таки не должны напоминать борьбу с ветряными мельницами.
> Учиться надо, вот оно в чем проблема-то.
Нет, проблема не в том. Проблема в том что затыкать самолично все типовые грабли - не очень прикольно. Хорошо что это стало до некоторых допирать наконец. А то как тут кто-то верно заметил - мы бы так и бегали за мамонтами с топорами. Ну может быть мы бы заменили камень на титановый сплав, а ручка была бы углепластиковой. Но врядли процесс охоты стал бы сильно безопаснее и эффективнее.
>> Да, только вот там простыни мутного кода на 2 страницы делают то же самое что в
>> нормальной системе инициализации делает конфиг на 5-7 строк. И даже меньше.
> Покажите этот мутный код в Debian, пожалуйста.
Дебианщики вроде как раз на похожий по смыслу апстарт и собирались (а потом может и на systemd). У меня к апстарту нет никаких претензий. Хотя если вы про обычные скрипты для инита - там даже простейший скрипт бывает _страницей_ текста, для совершенно шаблонных рутинных операций. На самом деле достаточно просто попробовать написать стартовый скрипт для какого-то своего сервиса. И подивиться насколько проще и быстрее это получится с хоть тем же апстартом. Попутно можно настроить плюшки которые в стандартном ините приходится густо окостыливать. Нет даже устаканившегося метода приоритет задать, каждый свой костыль депит если приперло.
> Постараемся поправить, если он действительно "мутный".
Что, вот прямо так во всех пакетах? 8-\ А вы какой пакет майнтайните в дебиане? Насчет всех и сразу не поверю - там майнтайнеры указаны разные.
> А вот "то же самое за 5 строг" - фиг сделаете.
Это почему же? Я как раз сделаю за 5 строк типовые операции, а в случае если надо что-то совсем уж из ряда вон - там и будем звать уже хелпера в виде скрипта. Насколько часто такое будет надо - см. выше.
> Откройте, пожалуйста, инит-скрипт apache2 и расскажите как
> реализовать тамошнюю логику на 5 строк.
Внезапно,
1) Я не люблю опаче за общую монструозность. Его скрипты - вполне в духе опача.
2) Это ж надо, из того же апстарта можно и шеллскрипты пинать, если надо.
3) Он даже умеет эмулировать из себя античный init, притворяясь шлангом для как раз таких бакланов которые никак не могут свои каменные топоры выбросить уже наконец. В отместку конечно скорость (ре)старта проседает, но врядли это юзеров монстров типа опача вообще интересует.
>> 1) Init не поставит сервису нужный приоритет по простому.
> Для этого и есть скрипты. Ставьте, пожалуйста. Хоть для процесса
> сервера - хоть для всех процессов из сценария.
Нахрен надо - 1 строка в конфига апстарта. В сто раз проще и быстрее написания самолично скриптокостылей. И работает. Без дерга на это огромного интерпретера и что там еще, которые в сумме работают дольше чем стартует сервис.
>> 2) А если нам надо запустить сетевой демон не раньше чем законектится вон тот сетевой и-фейс
> Для этого есть порядок последовательности запуска скриптов.
А также, если меня не подводит склероз, в этом случае было "очень умное" ничегонеделание системы пока всякие там сетевки раздупляются, получая айпишники по дхцп. Хотя по логике можно бы запускать тех кому сеть вообще не сдалась или конкретная сетевка не требуется. Но конечно же неандертальцам это недоступно. Зачем же геморроиться с выплавкой стали, если можно лианой камень к палке примотать?!
> И давно есть зависимости в заголовке LSB-совместимого сценария, чтобы все это
> было просто настроить.
Понятия о простоте у всех разные. Как по мне - 1 строка в конфиге апстарта это проще некуда. Попробуйте переплюнуть. Глядя на простынки текста в кило весом и больше - да ну его такое нафиг.
>> 3) Кому как не запускалке виднее всех что сервис внезапно нае..лся когда его не просили об этом?!
> "Запускалке" видно только то, что процесс с данным PID - умер.
А что еще она должна видеть? Именно это от нее и надо. И на скриптах конечно такое родить можно. И даже делают такое. Только геморно. Как зубилом письмо на каменной табличке долбить примерно.
> Или что больше в этой cgroups нету процессов. Увы, сервис
> может быть запросто в состоянии "нае...лся" и при этом не сегфолтиться
> и не завершаться.
В принципе - может. Поэтому неплохо бы еще и простую валидацию в духе monit. Типа сделать соединение по тцп. Отвечает - ок, не отвечает - дыщ, рестарт. В апстарте такого пока еще нет и такое все-таки придется закостылить. В systemd вроде как что-то такое значилось в планах. Правда вот это Поттеринг, чьи программы отличаются неоднозначностью. У него бывают здравые идеи, но вот их реализация оставляет неоднозначные впечатления.
> И сценарии решения этой проблемы могут быть сложнее "убить и перезапустить" -
> вот почему и есть monit.
Остается только вопрос нахрен при этом нужен init который ничего не умеет.
> Возможно, нужно логи почистить, возможно запуститить какой-то анти-ddos скрипт.
Запуск программы по расписанию - по большому счету разновидность запуска программ. Поэтому, если не ошибаюсь, авторы апстарта и/или системд и на кроны зубы точат, что довольно логично :)
> Или - отладчик подключить. Все это - не задачи для простой пускалки сервисов init.
Да у инита вообще нет задач. И хрен бы с ними с наворотами типа антиддосов, а вот всякие выставления приоритетов, рестарт упавших и взлет в правильный момент времени когда система к этому уже готова - хотелось бы видеть. В инит всего этого нет а в 100500й раз втыкать стандартный костыль - ни разу не прикольно.
>> 4) А вот если сервису стало ну совсем плохо, не надо перезапускать его 100 раз в секунду, чтобы не создавать сильную нагрузку на хост тупым рестартом без перспектив!
...
> Вот и я написал о том, что "не надо". Только и
> "забить" - не обязательно лучшее решение. Еще парочку я набросал
> выше. Поймите одно: Единственно Верной (тм) политики разрешения таких проблем
> - нет и быть не может.
Так я не спорю что для особо хитровы...тых случаев скрипты или внешние мониторы не лишние. Но для типовых случаев хотелось бы менее костылированных решений.
> Это задача для гибко конфигурируемой системы мониторинга (monit), а не для init
> и любой его альтернативы.
А я вот другого мнения. О monit знаю. Но честно говоря предпочту написать за 2 минуты простой конфиг с базовым рестартом и выставлением приоритета чем полдня сношаться с реализацией этого на шелскриптах и прикручиванию потом к этой куче monit.
>> Да вообще-то, если современный запускач реализован _нормально_, делая ВСЕ что от него надо, monit должен стать всего лишь костылем с повторным функционалом. Monit решает вполне стандартные проблемы администрежки. Они настолько типовые что почти все из этого списка по уму должен уметь сам init. Или на кой он нужен если ничего не умеет?
> sysv init умеет: стартовать сервисы в нужной (определяемой их зависимостями) последовательности.
А каменным топором в принципе можно зарубить мамонта. Но я все-таки предпочитаю не рубать мамонтов каменными топорами. Хоть это и можно, да.
> Все. Вы хотите из init сделать систему мониторинга?
Я бы хотел там видеть в том числе и какую-то базовую систему мониторинга живости сервисов которые он же и запускает, чуть больше чем просто отслеживание падения процесса. Как раз чтобы не изобретать свой велик (зато с турбонаддувом) на стандартную задачу.
> Она должна поддерживать тесты кучи протоколов, да еще и настраиваться автомагически?
По минимуму хватило бы простой проверки ответа сервиса на порту.
Чуть получше: уметь посылать заданный набор байтов и проверять что в ответ приехал ожидаемый ответ. Просто сделать, много веса не добавит. А вот в 90% случаев разгрузит человека от работы по рутинному костылингу стандартных проблем.
> Накой тащить функционал, единственной разумной настройкой по-умолчанию которого будет
> - "отключить нафиг".
Для вас разумны одни дефолты. Для других - другие.
> Поймите, что нет универсального способа настроить ПО типа monit. Например, действие
> по-умолчанию для apache может быть "перезапустить n раз и потом забить"
Ну так апстарт умеет делать не более чем эн рестартов за эм секунд. Если больше - считаем что сервис окончательно одурел и забиваем на это чтобы не нагружать хост тщетными потугами его застартить.
> - толку от ПО с таким умением будет 0, исключая сегфолтящиеся поделки Поттеринга.
Как минимум апстарт мне вполне доставил. Нафиг-нафиг писать портянки в 2 страницы когда можно накидать конфиг в 5 строк, справляющийся не хуже. А если вдруг надо что-то совсем из ряда вон - ну вот тогда и будем пинать скрипт-хелпер. Только сие надо после дождика в четверг. Что ведет к уменьшению геморроя у админа.
> Нормальный тест сервиса должен включать проверку работы бизнес-логики
> приложения, возможно с оглядкой на другие процессы или ресурсы в системе.
Нет, я конечно понимаю что можно дойти вплоть до написания юнит-тестов для апача, но это будет слегонца перебор, потому что в конечном итоге сбои в бизнес логике - это уже явно не в компетенции администратора и лечить сие должны програмеры :)))
