[del]
> Ну тогда - добро пожаловать в Дахау. Стройте всех разработчиков и
> читайте им лекцию на тему того, какие действия ихний демон должон сделать при старте Я никого строить не собираюсь, время само выпилит мамонтов в пользу млекопитающих.
[del]
> и сколько гемороя на С ради этого они должны тащить.
Демоны один хрен пишутся на си. И никакого геморроя в этом нет. Вот колупать простынки весом в полсырца демона чтобы только запустить его так как надо - это геморрой, да.
> Эффект предсказуем.
Я уже на себе ощутил его. С апстартом. То что раньше я делал за 2 часа копания в кривых и глюкавых скриптах писаных какими-то лабухами на коленке да еще с хардкодом имени сервиса и прочих радостей прямо в скрипте в середине оного, теперь делает конфиг на 5-7 строк который набрасывается за 5 минут из первой же нагугленой болванки (можно даже ман не читать, все и так очевидно). С точки зрения администрирования - небо и земля.
>> Я не сомневаюсь что можно прошибить все стены своим лбом. Но слегка утомительно
>> костылить все _стандартные_ типовые случаи.
> Что в точности вкладывается Вами в понятие "_стандартного_ типового случая"?
Например, собрал я некую прогу. Которой в репах нет. Демона, ессно. Что еще на серверах кроме них водится? Надо стало быть запустить. А вот тут опа. Потому что стартового скрипта обычно или нет совсем, или он кривой до ужаса. Никакого вам мониторинга состояния демона не умеет. Или это делается адски криво (вплоть до прописывания в крон скрипта-чекера который раз в несколько минут ищет pid и перезапускает демон если pid не найден).
> Делает что? Как выглядит оный для апача?
Без понятия: не пользуюсь (апачем, за тормознутость). Да и для апача - какой-нибудь скрипт или конфиг рабочий всяко будет в пакете, поэтому мне с его написанием геморроиться не придется. А вот для чего-то отсутствующего в репах (или даже самописного) - этого быть ни разу не обязано. И это запросто может стать именно _моей_ проблемой. А я получаюсь шкурно заинтересован чтобы такая вполне типовая проблема решалась просто и быстро.
> Кроме того, сколько стартует система - лично меня мало интересует. Этот
> старт происходит раз в полгода.
Меня для начала волнует мое удобство. Многокилобайтные простыни которые не обеспечивают даже элементарного рестарта сервиса при откровенном его падении - как-то не сильно удобно и требует кучи костылирования.
>> Bash стандартный весит как раз столько. Если не больше.
> Кто-ж виноват, что Вы bash используете в init-скриптах?
Не, давайте я еще буду разучивать языки 100500 разных интерпретаторов. Вот всю жизнь мечтал изучить все существующие на планете интерпретеры, аж два раза (для надежности).
> Для талантливых, повторю: запуск каждого сервиса происходит _один раз_ при старте системы.
Вообще-то это ниоткуда не следует. Вообще, есть еще всякие шедуленые мероприятия, изменения состояний системы и прочая.
> При остановке - происходит обратный процесс. Это типичный сценарий
> (все чуть сложнее, есть разные runlevel). А система может работать годами.
Может работать. А может не работать. А еще надо б мониторить что сдохло. А еще надо б по расписанию гонять задания. А еще неплохо б отслеживать различные события. И так далее.
> И, извините, Вы опять врете. Помимо exec* - Вам может понадобиться
> приоритеты выставить, лимиты и проч. Так что даже в Вашей
> радужной сказке - там отнюдь не один сисколл.
В простейшем случает один. Ну пусть даже пяток, с лимитами и приоритетом. По факту получается 5-7 строчек конфига. Что намного лучше тех мегарпостыней где г-но размазано по простыне на 2 страницы в меру дури ее автора, где в середине порой захардкожено имя сервиса и прочее. Всякие там приоритеты и лимиты авторы скриптов вообще не реализуют - это мне самому предлагается докостылить. Самым простым докостылингом выглядит дописать пару строк в мизерный конфиг, а не лопатить простыню на 2 экрана, извините.
>> Они для начала не решают проблему с мониторингом упавшего сервиса вообще.
> Они для этого и не предназначены. Это статические ограничения.
> Мониторингом занимаются специальные программы.
Угу. А инит вообще непонятно чем занимается. Висит в памяти все время работы ситемы. Больше он нихрена не умеет. Поэтому докостыливать всякие там расстановки приоритетов/лимитов/перезапуски и прочее приходится самолично. Вот радости то, каждый раз делать одну и ту же мартышкину работу в не сильно удобном виде.
> Вранье. Есть эти пакеты в дистрибутиве. Ничего более. Приоритет extra - nuff said.
А потом удивляются когда википедики всякие валят на убунты, а не дебиан. Ну вот админы - тоже люди. И чем удобнее и быстрее с системой управляться - тем лучше. Особенно если серверов много а админов мало.
>>> Постараемся поправить, если он действительно "мутный".
>>Что, вот прямо так во всех пакетах? 8-\ А вы какой пакет майнтайните в дебиане?
>>Насчет всех и сразу не поверю - там майнтайнеры указаны разные.
> Вы, главное, не переживайте. Я не поправлю - сделаете баг и другие поправят.
Я и не переживаю: при наличии целой кучи дистров можно просто выбрать тот в котором наиболее удобно. Так, на подумаь: в серверной убунте менее архаичный софт, более удобная система инициализации и есть на выбор LTS ветка для тех кому стабильность, и обычная для тех кому свежак. Поэтому ее юзеж на сервере в общем случае для меня менее геморроен. А апстарт - мелкая, но довольно приятная фича. Вносящая свою капельку веса при складывании разных дистров на разные чаши весов и принятии решения "а чего же мне все-таки использовать из всего этого великолепия у себя?"
> Главное, что Вы блудословие прекратите и приведете пример реальной проблемы.
Реальная проблема: сервис которого нет в репах. Самосборный или еще не попавший в оные. Мне написать ему конфиг для апстарта в 10 раз проще и быстрее чем возиться с скриптошитом на несколько страниц, которые сделает то же самое, но с куда большей возней и хучшим результатом.
>> Внезапно,
>> 1) Я не люблю опаче за общую монструозность. Его скрипты - вполне в духе опача.
> Не асилил?
Нет, просто открыл для себя nginx и lighttpd и узнал что серверу совсем не обязательно быть 16-ядерным монстром с 128Гб оперативки чтобы выдерживать целую толпу народа.
Кстати верно замечено: у меня нет цели "осилить именно апач и никак иначе". Я совершенно иными целями оперирую. Вот "показ юзеру странички форума" или там "отдача файла", желательно подешевле и пооптимальнее - это да, годная цель. А "асилить" и "понтануться" - это видимо что-то такое "для риальных пасанов на раене", с такими целями - не ко мне.
> Ну вот вам и контингент пользователей systemd...
Ну вообще-то апстарта в основном, но это не мешает признавать что systemd местами задуман неплохо. Вот правда реализует это Поттеринг, что как-то стремновато, увы.
> Такой гибкой архитектуры, как у апача - еще поискать надо.
Такой жуткой архитектуры и реализации как у апача - еще поискать надо. Получился огромный и тормозной ресурсожоркий переросток, благодаря которому некоторые искренне полагают что машины с менее 16 ядер и 128 гиг памяти сервировать в принципе не способны, даже 10 человек.
> Что "шеллы пинать" возможность есть - эт хорошо, конечно. Но не
> лучше ли сразу признать, что никому кроме десктопов эти ноухау нафиг не сдались?
Да я как-то и на сервере не дурак попользоваться апстартом. Потому что мне тупо удобнее и куда быстрее прописать 5-7 строк конфига чем ворочать многокилобайтные портянки, зело непохожие друг на друга и очень разные по качеству кода в них.
> Как что-то полезное запустить, не из поделок Песателя
> - так вон сразу и шеллы приходится...
Да вообще-то я несколько нужных лично мне демонов недавно на серваке запустил через апстарт. Доставило. Это оказалось намного проще и быстрее чем, простите, то же самое на шеллскриптах городить через инит. Вот напрасно я боялся этого апстарта, наслушавшись всяких козлов, что там все извратно и сложно. Оказалось что просто как топор, пример конфига гуглится за 5 минут и вообще намного проще чем колупать портянки на 2 экрана весьма различные по конструкции (или отсутствующие) у разных авторов софта.
>> пока еще нет и такое все-таки придется закостылить.
>> В systemd вроде как что-то такое значилось в планах.
> Совать такое в аналог init - тупо. Либо получите монстра, там
> где была простенькая программа с ясным поведением.
И в каком месте тот же monit монстр? По сути это почти инит, только сделанный менее через задницу и куда более соответствующий жизненным реалиям. Остается только вопрос - а нахрен инит место в списке процессов тогда занимает, ась? Бесполезный балласт.
> Либо получите недомониторинг, который при более-менее серьезном применении
> нужно просто выключить.
Нормальные программы имеют свойство быть модульными и допускать внешние компоненты. Тот же monit не такой уж и монструоный в общем то.
>> А что еще она должна видеть? Именно это от нее и надо.
> Повторяю, "именно это" - надо только сегфолтящимся приблудам для десктопа. Нормальному
> мониторингу это будет только под ногами мешаться.
Это скорее инит с его обрубками будет под ногами мешаться. Нифига не умеет но почему-то за главного. Нафиг-нафиг, за столько лет уже можно наконец сделать выводы о типовых граблях из жизни демонов и разгрузить админов от костылинга этого самолично.
>> Остается только вопрос нахрен при этом нужен init который ничего не умеет.
> Он умеет. Запустить программы в заданном порядке при переходе с уровня
> на уровень. Очень простой, понятный и логичный функционал.
Да, просто немного не соответствует современным требованиям, а так сущая ерунда.
> Это unix. Другие программы - делают разные другие полезные вещи.
Linux к счастью не юникс. Поэтому те кто хочет орудовать каменным топором, 1970-х годов разработки - в своем праве. А я вот пришел к выводу что на основе опыта хорошо бы делать выводы.
> Ну, шелл - тоже умеет программы запускать.
И еще много кто. Чем шелл лучше них?
> Его еще нет в планах?
Не думаю. Чем шелл лучше остальных? И не вижу особых проблем от запуска внешнего шелла.
> Задачи init я Вам уже пару раз описал. Повторяться уже лень.
Если честно - мне глубоко пополам на какие-то там "задачи init". А это кто такое и почему это меня должно интересовать? Мне не пополам на _мои_ задачи и насколько много геморроя у меня будет. Вы прикиньте? :)))
> "Выставления приоритетов" (и многое другое для статического ограничения ресурсов) -
> делаются в init-скриптах.
А в апстарте такое делается тупо в конфиге оного. Что проще и быстрее.
> Один раз.
Что, благородный дон замуровывает сервера в стену? А я вот иногда могу возжелать доуствноить какой-то еще сервис, если полагаю что это надо.
> При настройке системы.
Уй, надо еще добавить что 640 кило хватит всем. Чтобы уж наверняка.
> Это задача администратора.
И я шкурно заинтересован чтобы мне было просто и удобно разруливать мои задачи. Внеазпно.
> Для того init-скрипты в любом дистрибутиве представляют собой
> конфигурационные файлы.
Обычно они являют собой месиво из г-нокода, констант распиханых по всему файлу а порой и имен сервисов захардкоженых где-то в середине скрипта.
Особенно хорошо когда нужного сервиса нет в пакетах, поэтому где я возьму скрипты - резко превращается в мою проблему. При этом узнаешь много нового о качестве кода, г-нокоде, месиве и что где захардкожено, когда пытаешься взять за болванку чье-то готовое от соседнего демона, казалось бы достаточно похожего по смыслу.
В такой ситуации ака "старт с нуля" как-то оказалось что проще всего накатать конфиг апстарту, а вовсе не городить многоэтажные макароны из кучи шеллскриптов.
> И upstart/systemd за Вас данную задачу не решит магически.
Конечно. Что так что сяк мне придется в одном случае писать конфиг, в втором писать или дорабатывать скрипты. Первое получается намного проще и быстрее и потом результат куда приятнее для глаз. Как бонус еще и система быстрее стартует.
>> Я бы хотел там видеть в том числе и какую-то базовую систему мониторинга живости
>>сервисов которые он же и запускает, чуть больше чем просто отслеживание падения процесса.
> Ее настраивать надо. Это _сложно_ и ровно нет никакой возможности настроить
> подобное автоматически.
Да чего там сложного? Самый тривиальный и действенный метод верификации демона сводится к всего 3 кусочкам в конфиге.
1) Что и куда послать, по какому протоколу, etc.
2) Что и за какой таймаут должно приехать в ответ.
На основании подобной логики вполне можно делать вывод о живости типовых сетевых демонов и их работе. Анализ всякой бизнес-логики уже не дело мониторинга, пожалуй. Там все-равно програмеры смогут накосячить кучей методов неуловимых автоматически. Иначе б автотесты давно уже привели бы к искоренению багов как таковых. Чего как-то не наблюдается.
> 99% функционала отключено нафиг по-умолчанию.
См. выше чего хотел бы видеть в такой штуке лично я. Это позволит чекать кучу сервисов от хттп сервера до почтаря вполне адекватно проверяя их живость и способность ответить за таймаут. По минимуму около 2-3 строк конфига выходит. Всякий совсем ынтерпрайз конечно пихать туда ни к чему (хотя если кому надо и они напищут себе отдельный плагин, врядли кто будет отбиваться ногами).
>> По минимуму хватило бы простой проверки ответа сервиса на порту.
>> Чуть получше: уметь посылать заданный набор байтов и проверять что в ответ приехал
>> ожидаемый ответ. Просто сделать, много веса не добавит. А вот в 90% случаев разгрузит
>> человека от работы по рутинному костылингу стандартных проблем.
> В 90% процентах - это лишний спам в ящике.
Какой спам? В какой ящике? Кто и зачем будет спамить?
> Нету телепатии - до эры AI подобные вещи будут настраиваються людьми. Примите
> это как факт. Вот почему в любом дистрибутиве - есть только _примеры_
> для скриптов/конфигурации систем мониторинга.
Опять же, настраивать ынтырпрайзный мониторинг чтобы чекать аж почтарь, хытытыпы и какойнить там днс на мелком сервачке - явный оверкилл и подобное вполне мог бы делать и тот кто их запускает. Нехай станет не только запускачем но и супервизором работы, пусть не самым забористым но покрывающим 90-95% простых случаев и осваиваемый за 2 минуты. Геморроиться с расстановкой костылей для этого лично - не очень охота. Доставать ынтырпрайзные махины для проверки того что хттп сервак не сдох - тоже.
>> Для вас разумны одни дефолты. Для других - другие.
> Вот в этом и проблема. Для десктопа манагера Васи - придется точно также
> отключить по-умолчанию весь вумный "мониторинг", равно как и для сервера "админа" Коли.
Что значит - отключать? Включаться он должен только если я изъявил желание чтобы сервис мониторился на живость. Куда-то по соседству с настройками рестартов и их допустимого количества.
> Единственный разумный вариант по-умолчанию: если упало - значит что-то не так, пусть
> админ посмотрит и разберется. Падать - не должно.
Падать не должно. Но если это какой-то автомат стоящий в чистом поле за тридевядь земель, посмотреть и разобраться может означать поездку за сотни километров в какую-то ж-у мира чтобы какой-то хренов демон поднять. Особенно весело будет если это по причине типа "из космоса прилетела частица с высокой энергией и перевернула таки битик в нужный момент".
> Сообразите где это умолчание реализовано? ;)
У меня немного другой взгляд на проблему. Фэйл должен быть залогген и я должен бы получить о нем уведомление, но вот караулить постоянно как цербер? Лично? Окарауливайте, я не против. Вахтер тоже человек.
>> Ну так апстарт умеет делать не более чем эн рестартов за эм секунд. Если больше -
>> считаем что сервис окончательно одурел
> "эм" - это не число. Это буковки. Сколько это в цифирь?
По вкусу и здравому смыслу. Я например полагаю что если сервис умер более 5 раз за минуту - тут что-то капитально не так и он сломался окончательно, так что дальнейшие попытки подъема чреваты только лишней нагрузкой и шансами пригрузить систему постоянными рестартами процессов, с шансами усложнить алмину ремотный вход. Но поскольку параметр настраиваемый, каждый сам решает сколько вешать в граммах.
> Какому сервису какую цифирь выставить?
На усмотрение админа, имхо. Что использую я в типовом случае я написал. Для каких-то сильно монструозных или специальных применений цифры наверное могут быть и иные. Если сервис только взлетает минуту, вероятно окно мониторинга стоит сделать в несколько минут минимум чтобы успешно ловить циклические рестарты чреватые большой нагрузкой на систему.В моем случае минута - с большим запасом, а 5 - порог моей толерантности к частоте падений сервисов после которого я начинаю всерьез полагать что "легче пристрелить чем прокормить".
> Не получит ли мейнтейнер пакета по мордасам за то, что выставит эти цифирки?
Не думаю. А за что? В дефолтах все-равно на всех не угодишь, а какие-то прописывать надо. По вашей логике все майнтайнеры должны дружно ходить с синей рожей. А то параметров много разных. И дефолтов для них. Безотносительно к upstart/systemd/прочим, в те или иные дефолты что-то приходится прописывать.
[del]
>> это будет слегонца перебор, потому что в конечном итоге сбои в бизнес логике - это уже
>> явно не в компетенции администратора и лечить сие должны програмеры :)))
> Речь быле не о юнит-тестах. Апач может быть жив-живехонек, а скриптам
> отказано в каких-то ресурсах.
Может. Однако _все_ ошибки такого класса вы _никакими_ мыслимыми тестами не поймаете. Это не я придумал. Есть такая теорема что одна программа никогда не сможет полностью и достоверно выдать заключение о том как работает другая произвольная програма. Вы хотите делать то что невозможно даже теоретически? :)
А с простым вариантом справится и простой монитор:
1) Шлем на адрес:порт вот это, это и это. Пусть "это" будет запросом к скрипту с ожидаемым результатом.
2) Проверяем что за таймаут приехал ответ ожидаемого содержания.
Это базовая проверка что демон не сдох и работает. Остальное уже явно выходит за компетенцию запускалки. Хотя-бы потому что всякие там обломы прав доступа и прочие багоглюки рестартом сервиса вообще не лечатся.
> Причем, проявиться это может не на главной странице, которая из кеша
> какого-нить достается, а когда клиент веб-магазина насобирает себе корзину
> и нажмет кнопку "я хочу дать Вам за это бабло"...
Это на грани невозможного (анализ поведения одной программой другой произвольной программы). Как бы вы ни изгалялись, а такой шанс останется всегда. Транзакции не от хорошей жизни придумали. А как раз чтобы минимизировать вред от факапов когда все навернулось в именно такой вот момент. И в любом случае это уже не компетенция запускалки: если у вас скажем место закончилось и не удается лог записать, то сколько ни перезапускай сервис, ничего не изменится. Что монитор может сделать? rm -rf / разве что? Единственный универсальный патч от всех бед :)
