>> А вот внедрить в него то, чего он не умеет, будет на порядок сложнее,
> Поэтому кульсисоп среднего пошиба может как и раньше набросать скрипт, если иначе
> слвсем никак. Речь о том, что при внедрении своих скриптов, нужно быть точно уверенным, что systemd не вмешается в их работу. Для этого нужно знать всю внутреннюю логику работы systemd, а это не 15 строк скрипта.
>> чем в простую инит систему.
> Туда отродясь никто никаких фич не запиливал. Инит не умеет чуть менее
> чем нифига.
В этом и смысл - что их можно безболезненно править и не боятся, что они будут вмешиваться в работу друг друга.
>> Пример того как у меня работает сеть на ноуте я приводил ранее:
>> https://www.opennet.ru/openforum/vsluhforumID3/100356.html#434
> А еще там пример гениально ... гунявого управления сервисами, в хучших традициях
> скрипткидей. С while true. Подумайте что будет с этим однострочником, если
> сервис фатально издох. Подсказываю: скоростной рестарт в цикле тяжелого сервиса может
> вклинить всю систему. Знаете как здорово, когда система радостно рестартует тяжеленный
> сервис на скорость, а менеджмент интерфейсы при этом клинит? Вот чтобы
> такое у...ство раз и навсегда развидеть - появились апстарт и системд.
> Где это сделано нормально. Без левых допущений, халтуры и упрощений! Мне
> так больше нравится чем ваш IT-джамшутинг. Работает потом лучше.
Я с вами как с компетентным человеком разговариваю - а вы просто в душу ...
Я и так там написал - "Сообщение в логи/на email/sms добавить по вкусу :)"
Я должен был написать как для полного идиота - вставьте задержку/максимальное количество итераций?
>> Не уверен, что это легко получится реализовать через systemd и не получить
>> различных косяков в совершенно неожиданных местах.
> Продвинутые сетевые конфигурации через системд делать довольно странно.
Ну вот и приплыли: а чем он вообще занимается, если даже нельзя полноценно расписать реакцию при изменении состояния железа? Зачем он тогда в себя udev втянул?
>> Но systemd пытается спрятать проблемы, а не решить их.
> Я почему-то вижу скриптокидозниов рассказывающих мне про то что фичи "не требуются".
ИМХО фичи должны быть отдельными простыми программами, слабо зависящими от конкретной системы инициализации.
>> Все же вы существенно преувеличиваете. В большинстве случаев достаточно одной-двух строк.
> Я видел как такой трэш потом работает. "А потом мы подумаем что
> будет с системой, если у тяжелого сервиса побились рантайм данные и
> он не взлетает". После того как пяток админов хорошенько обложит "кoзла"
> "матами".
Что мне нужно сделать в systemd для получения эквивалента "nc -ll -p 7777 -e /usr/libexec/sftp-server &"? Это будет проще, понятнее, надежнее?
Приведите выщ реальный пример запука сервиса и требования, и посмотрим насколько сложно для него написать запуск.
> У меня логика простая: система или делает то что должна, или уходит
> в ребут и восстанавливается в известное, работоспсобное и безглючное состояние. Работу
> в глючном режиме или длительный клин - считаю неприемлимыми вариантами в
> имеющихся задачах.
Ну и толку - сдохла видюха на сервере, получим бесконечный ребут, без возможности удаленно зайти на машину.
> Если система совсем умерла - человек еснно требуется, как
> и анализ причин "а чего это оно". Но знаете, даже дубовые
> электрики, с незапамятных времен просекли что до того как посылать бригаду
> к черту на рога, есть смысл попробовать пару раз попытаться перезапустить
> линию на автомате.
А то вдруг пьяного мужика, подключавшего сварку к 10KB еще не добило или заклинивший движок только начал перегреваться и еще не сгорел ...
> Компьютеры, конечно, иное. Но сам по себе инженерный
> принцип, имхо, имеет право на жизнь. Потому что у компьютеров сбои
> тоже делятся на "transient" и "permanent". Да-да, любой разработчик и QA
> в курсе что бывают баги/сбои которые вы видите 1 раз в
> своей жизни. Сказки про то что их быть не должно -
> круто, но - не про эту планету.
Согласен, но выводы совершенно иные - во многих ситуациях тупой перезапуск через вачдог может сделать еще хуже. Если уж серьезно относится к безотказности - то я бы сделал отдельный девайс для ресета, который ждет sms/email с паролем.
>> Если железо нормальное, то вероятность такого расклада (зависание сервиса без segfault)
>> очень мала.
> А я вот видал и "зависания без segfault" тех или иных программ,
> поэтому ваши аргументы для меня звучат как отмазка.
Естественно они есть, но причем здесь вачдог? Вачдог нужен когда железо/драйвер шалит, дабы обнулить состояние всех регистров и стартануть все с нуля.
Если завис просто софт - killall его (рестарт по вкусу), а остальные сервисы/приложения должны продолжать работать.
> Т.к. все это совершенно не критично к скорости, а передерг питания "Pi"
> крайне нежелательное событие, мк - лишний элемент системы. Дернуть GPIO может
> и Pi-образный девайс, если требований к скорости нет. При том в
> системе меньше компонентов, следовательно она надежнее.
Pi-образный девайс на два порядка сложнее МК, соответственно вероятность отказа на два (а может и более) порядка выше.
> В конце концов, мк тоже
> может умереть. Любители атмелок с тиражами вам расскажут. И про нулевые
> ячейки еепрома и про слет флеша :)
Для особо критичных задач МК можно продублировать - на цене это особо не скажется.
Да и пока в своей практике я не видел зависшего МК, хотя многие работают 24/7. Чего не скажешь про ПК/роутеры/3g модемы/карты памяти.
Был случай когда непомерные EMI в системе зажигания приводили к перезапуску, так движок даже заглохнуть не успевал между перезагрузками МК :)
>> И программу можно сделать bug free практически сразу и вачдог на случай аппаратного
>> зависания есть.
> Так у моих ARMовых борд он тоже есть. Да что там, у
> ноута и десктопов - и то в чипе SuperIO нынче вачдог
> до кучи встроен.
Да но гарантировать bug free всего программного комплекса на RBPi/ПК невозможно, в отличии от МК.
