>> что systemd не вмешается в их работу.
> Systemd - не искусственный интеллект. Ничего особенного со скриптами он не делает. Как уже отметили, речь об состоянии системы, а не о интерпретации скрипта. Systemd/udev может изменить право доступа или имя устройства или создать динамически генерируемый конфиг - все это делает систему менее предсказуемой, сложнее точно сказать какие будут произведены действия в той или иной ситуации.
> А еще, если вы про экономию ресурсов - интерпретер шелла, висящий на
> каждый while true - ресурсов кушает. Поболее чем systemd на отслеживание
> процесса.
Возможно, но не думаю что разница существенна при использовании sh (ash/dash)
> Посмотрите man systemd.exec, systemd.unit и systemd.service
Я принял ваши доводы. В большинстве случаев вся эта функциональность бесполезна, но для определенных ситуаций/сервисов может быть необходима. ИМХО хорошим решением было бы вынесением создание отдельной утилиты отвечающий за запуск сервиса (с обработкой ошибок, таймаутами, etc), не зависящей от системы инициализации. Тогда бы ее можно было бы при необходимости использовать с любой системой инициализации - и все довольны: не хочешь не используй и единое решение для всех дистрибутивов/систем инициализации. А проекты типа busybox могли бы включить облегченную реализацию.
>> Ну и толку - сдохла видюха на сервере, получим бесконечный ребут,
> Это какой-то совсем сферический юзкейс в вакууме. Для начала, в обычные сервера
> (и эмбедовку) нынче обычно не ставят дискретные видеокарты - 2015 год
> на дворе.
То есть вы считаете что lockup видео драйвера происходит исключительно на дискретных видиокартах? Я видео карту как пример взял, так как сам тут поймал регрессию на радеонах ведущую к lockup в kernel-4.1. При том как на дискретной, так и на чипсете.
>> без возможности удаленно зайти на машину.
> Сервер крутится без графики и поэтому клин 1 из GPU всем пофигу.
А как же - "У меня логика простая: система или делает то что должна, или уходит в ребут и восстанавливается в известное, работоспсобное и безглючное состояние." ?
>> Если уж серьезно относится к безотказности - то я бы сделал отдельный
>> девайс для ресета, который ждет sms/email с паролем.
> А кто будет проверять проверяющего? И вас не смущает, что сотовый модем
> - это еще несколько мегов черти-какого кода, сложный протокол, целая ОС
> в симкарте, и в общем то не очень надежная сеть?
Любое дублирование существенно повышает шансы на безотказность. Можно взять три ненадежных элемента - ПК, сотовый модем с gpio, RBPi (ждущий email с паролем для ресета). И получить достаточно безотказный удаленный ресет.
> Не говоря о том что сотовый модем ощутимо удорожает и усложняет конструкцию.
Цена, это отдельный разговор - просто так (а бы было) такое никто сооружать не станет, а если будет реальная необходимость - то и продублируют, вплоть до управления со спутника.
> Надежность такой сбрасывалки будет врядли выше надежности вачдога. И будет много
> иных факторов. Ну там сотовый модем. Его ОС и вачдоги. И
> насколько он там выкручивается из разных ситуаций.. нуу... вот вы как
> раз на себе и протестируете ;].
Всякие космонавты для таких случаев берут несколько девайсов на разных производителей и на разной элементной базе.
>>> поэтому ваши аргументы для меня звучат как отмазка.
>> Естественно они есть, но причем здесь вачдог? Вачдог нужен когда железо/драйвер шалит,
> Вачдог нужен для восстановления работы сбойнувшей системы в ожидаемое состояние, за разумное
> время, без внешний воздействий. Причин по которым система может сбойнуть -
> много. И многие из них - transient.
ИМХО пока ядро живо, должны использоваться менее агрессивные средства (типа killall), а вачдог должен сработать только при зависании ядра либо при глухом (killall и рестарт не помогают) зависании служб/драйверов необходимых для удаленного управления.
>> Pi-образный девайс на два порядка сложнее МК,
> А связка Pi-образный + МК будет еще сложнее чем каждый по отдельности.
> А основы теории надежности говорят нам что так будет еще менее
> надежно.
Нет, в поставленной вами задачи - мы выносим критическую задачу на МК (таймер и gpio), а не критическую (веб морда) на Pi-образный девайс.
>> соответственно вероятность отказа на два (а может и более) порядка выше.
> А с практической точки зрения - железяки показывают вполне приличную надежность.
Возможно, но когда я пытался управлять насосом с выделенного ПК (не было тогда Pi-образный девайсов), я быстро понял свою ошибку ;)
> Вот только сколько МК не дублируй, а например картинку с
> usb-камеры на хард микроконтроллером не запишешь. А юзер врядли будет рад
> узнать что девайс оказывается уже 2 дня груши околачивает и ничего
> не наблюдает.
Это совершенно другая задача, и как правило менее критичная, чем управление всякой автоматикой. Да и она в основном решается дублированием.
> Случаи разные бывают. И вы с вашими попытками серебряные
> пули втюхивать - смотритесь от "странно" до "глупо", имхо.
Я просто предложил наиболее оптимальное решение для озвученной вами задачи. Где я говорил про универсальность и серебряные пули? У вообще жизненная позиция - выбирай для каждой задачи свое наиболее подходящее решение, а не одно универсальное. Все универсальное (компромиссное) будет по определению хуже специализированного (без компромиссное), за исключением когда универсальность - это и есть специализация.
> Ну так я не собираюсь делать систему зажигания на апликушном проце. Там
> наверное приличные требования к реалтайму, а сильно много мозгов как у
> апликушника - куда их там?
Естественно.
>> Да но гарантировать bug free всего программного комплекса на RBPi/ПК невозможно, в
>> отличии от МК.
> Я вижу некое отличие между pi-like и писюком. В одноплатнике может быть
> 1 проц, без проприетарного кода (кроме может быть минимального boot rom,
> тривиального в анализе и логике работы). Это достаточно предсказуемая связка, где
> я контролирую все. Куда предскауемее писюшника с его BIOS, SMM и
> прочим крапом.
Как не крути, а что на PC что на pi-like - миллионы строк кода, ненадежная загрузка (карта памяти или винт). Да железа на два порядка сложнее МК. Можно конечно сказать что на pi-like надежнее по железу (проще система питания, проще система охлаждения, меньше разъемов), но ИМХО pi-like будет надежнее в 2-3 раза, а МК - на порядок или два.
