>> синонимом понятий "геморрой" и "много долботни на ровном месте".
> Это если systemd умеет делать то, что нужно. А если даже и не умеет - ВНЕЗАПНО, из него можно позвать скрипт. Только это будет надо весьма редко.
> А вот внедрить в него то, чего он не умеет, будет на порядок сложнее,
Поэтому кульсисоп среднего пошиба может как и раньше набросать скрипт, если иначе слвсем никак. Только вот т.к. админть это сложнее - это должно быть last resort. Стремный гомнокод вообще лишний раз в систему лучше не пихать. А инит скрипты чаще всего заслуживают именно такой эпитет почему-то.
> чем в простую инит систему.
Туда отродясь никто никаких фич не запиливал. Инит не умеет чуть менее чем нифига.
> Пример того как у меня работает сеть на ноуте я приводил ранее:
> https://www.opennet.ru/openforum/vsluhforumID3/100356.html#434
А еще там пример гениально ... гунявого управления сервисами, в хучших традициях скрипткидей. С while true. Подумайте что будет с этим однострочником, если сервис фатально издох. Подсказываю: скоростной рестарт в цикле тяжелого сервиса может вклинить всю систему. Знаете как здорово, когда система радостно рестартует тяжеленный сервис на скорость, а менеджмент интерфейсы при этом клинит? Вот чтобы такое у...ство раз и навсегда развидеть - появились апстарт и системд. Где это сделано нормально. Без левых допущений, халтуры и упрощений! Мне так больше нравится чем ваш IT-джамшутинг. Работает потом лучше.
> Не уверен, что это легко получится реализовать через systemd и не получить
> различных косяков в совершенно неожиданных местах.
Продвинутые сетевые конфигурации через системд делать довольно странно. С другой стороны, у меня network manager вон живет и ему systemd жить не мешает...
> Но systemd пытается спрятать проблемы, а не решить их.
Я почему-то вижу скриптокидозниов рассказывающих мне про то что фичи "не требуются". И Поттера, запиливающего фичи, вместо левых сказок. Как мне больше нравится - догадайтесь :)
> Все же вы существенно преувеличиваете. В большинстве случаев достаточно одной-двух строк.
Я видел как такой трэш потом работает. "А потом мы подумаем что будет с системой, если у тяжелого сервиса побились рантайм данные и он не взлетает". После того как пяток админов хорошенько обложит "кoзла" "матами".
Вот в апстарте и системд это сделано нормально. А на вашем велике из водопроводных труб вы сами и рассекайте, имхо.
> Фактически systemd просто спрятал то, что было в скриптах.
Сначала апстарт. И да, они это сделали по людски, без кучи дурных грабель в очевидных местах. А потом и системд. Они еще и доразвили идею. Для каких-то совсем хитрых случаев может и не хватит фич. Ну вот тогда я и буду и звать скрипты.
> ИМХО вачдог не понацея, а крайнее средство.
Ну разумеется. Только юзер прущий в тутуево чтобы передернуть питальник или нажать ресет - еще более крайнее.
> Если произошло зависание, то нужно искать и устранять причину, а не тупо перезагружать.
Если зависание случается раз в год - может быть напряжно год караулить баг, кукуя целый год в тутуево. Еще интереснее узнать что на самом деле это какая-нибудь космическая частица битик в памяти перевернула. А вот кадр которому придется двигать в тутуево чтобы нажать ресет - выскажет нелестные эпитеты. И будет по своему прав.
> или как подстраховка для всякой автоматики.
Ну да. На обычном десктопе юзер и сам ресет нажать может. Но мир не кончается на десктопах. На серверах ресет жать уже напряжно. Особенно тем у кого их 1000 штук распихано. А в эмбедовке, до которой добираться может быть дольше и дороже - тем паче. И линух, вы только подумайте, активно применяется на серверах и в эмбедовке. Да и на десктопе я не откажусь от человеческого прописывания параметров запуска процессов, руления контейнерами и прочая.
> само не уходит при kernel panic.
(думаю вы догадываетесь с какими дефолтами я билданул армовское ядро)
> С сервисами/драйверами еще менее однозначно
У меня логика простая: система или делает то что должна, или уходит в ребут и восстанавливается в известное, работоспсобное и безглючное состояние. Работу в глючном режиме или длительный клин - считаю неприемлимыми вариантами в имеющихся задачах. Если система совсем умерла - человек еснно требуется, как и анализ причин "а чего это оно". Но знаете, даже дубовые электрики, с незапамятных времен просекли что до того как посылать бригаду к черту на рога, есть смысл попробовать пару раз попытаться перезапустить линию на автомате. Компьютеры, конечно, иное. Но сам по себе инженерный принцип, имхо, имеет право на жизнь. Потому что у компьютеров сбои тоже делятся на "transient" и "permanent". Да-да, любой разработчик и QA в курсе что бывают баги/сбои которые вы видите 1 раз в своей жизни. Сказки про то что их быть не должно - круто, но - не про эту планету.
> делают - вачдог по-умолчанию не нужен, а кому он реально нужен
> - разберется и настроит.
Вроде как ядро нынче таки врубает железный вачдог, если он есть. Но сработает он только если умерло ядро. А системд ессно не вачдогит процессы по дефолту, пока не попросили явно. Тем более что это надо код дергающий апи системд в процесс дописать, как и в случае с вачдогом в прошивке. Зато если оно потребовалось - не надо писать логику этого самого вачдога самому.
> Если железо нормальное, то вероятность такого расклада (зависание сервиса без segfault)
> очень мала.
А я вот видал и "зависания без segfault" тех или иных программ, поэтому ваши аргументы для меня звучат как отмазка. А с практической точки зрения:
- Дописать пяток строк в конфиг и капельку кода - не выглядит высокой ценой за уменьшение предъяв.
- А вот самому писать ВСЮ логику вачдога-супервизора уже как-то явно перебор получается.
> Если железо с глюками - его менять нужно, а не ждать когда оно полностью встанет.
Идите, расскажите электрикам что они должы выбегать всей бригадой на любое отключение линии, а автоматический перезапуск - никак не можно. А электрики популярно и доступно расскажут вам что они думают о перспективе бегать к черту на рога в пять раз чаще... ;)
> дней: винт глючить перестал, новый покупать пока не буду. Через
> неделю - винт полностью обрубился, бэкапов нет ...
Случаи разумеется бывают разные. Но в эмбедовке например обычно флеш-память. У него failure rate конечно не ноль. Но он относительно предказуем в плане поведения. Не говоря о том что ему обычно жизнь пытаются продлить до состояния когда лимитом будет гарантированное время хранения данных из даташита на чип, а не что-нибудь еще. Ну и никто в здравом уме не гарантирует вечной жизни своих устройств, если что.
> А если реле залипнет ? ;)
Ну, знаете, если производитель гарантировал 200 000 срабарываний, которых хватит на следующие 100 лет - я ему и переадресую претензии. Ну и на будущее не буду иметь дело с таким брендом, если такое регулярно будет случаться.
> Тут однозначно управление реле (а лучше симистором/мосфитом) на МК,
> а все не критичное на ПК/RBPi/etc.
Т.к. все это совершенно не критично к скорости, а передерг питания "Pi" крайне нежелательное событие, мк - лишний элемент системы. Дернуть GPIO может и Pi-образный девайс, если требований к скорости нет. При том в системе меньше компонентов, следовательно она надежнее. В конце концов, мк тоже может умереть. Любители атмелок с тиражами вам расскажут. И про нулевые ячейки еепрома и про слет флеша :)
> И программу можно сделать bug free практически сразу и вачдог на случай аппаратного
> зависания есть.
Так у моих ARMовых борд он тоже есть. Да что там, у ноута и десктопов - и то в чипе SuperIO нынче вачдог до кучи встроен.
> У меня подобное ощущение и результативность от некоторых "облачных" технологий
Мне они тоже не очень нравятся. Я не фанат вендорлока.
