> Как уже отметили, речь об состоянии системы, а не о интерпретации скрипта. В многозадачке состояние системы всегда может меняться. Ну там часы могут например перевестись за счет NTP. Надо просто быть готовым к этому, в т.ч. и в коде.
> Systemd/udev может изменить право доступа или имя устройства
Может. Но для большинства девайсов это случается только при начальном добавлении или отключении устройства и иных нестандартных случаях. В этот момент программа в любом случае столкнется с исключительной ситуацией. Если там забили на ошибки - ССЗБ.
> или создать динамически генерируемый конфиг
В многозадачке появление файлов параллельно с работой вашей программы - штатная ситуация.
> - все это делает систему менее предсказуемой,
Вы изначально не должны делать допущений о том что ваш процесс или скрипт единственная сущность в многозадачной системе. Фундаментальная ошибка.
> сложнее точно сказать какие будут произведены действия в той или иной ситуации.
Если вам всегда нужно знать все и вся с точностью до бита - лучше не вылезать за пределы PIC-16 и систем уровня DOS.
> Возможно, но не думаю что разница существенна при использовании sh (ash/dash)
Когда их будет десяток - разница может стать заметной. Да и список процессов замусорен лишний раз. Наф-наф-наф.
> для определенных ситуаций/сервисов может быть необходима.
Ну вот у меня этих определенных ситуаций - везде. И я хочу видеть ряд фич системды и на десктопах, и на серверах, и в эмбедовке. А со сказками кому и что должно и нужно - только шиндошс продавать.
> таймаутами, etc), не зависящей от системы инициализации.
Система инициализации имеет очевидные плюсы:
1) Инит всегда запущен. Поэтому находится в нyжном месте, в нужное время, с нужными правами для того чтобы выступить супервизором. Не требуя по экземпляру на каждый процесс.
2) Инит всегда запущен. Не надо делать переинициализацию процесса -> быстрее.
3) Когда процесс инита создает новый процесс для запуска сервиса, у него все карты на руках чтобы в этот момент расставить все параметры. Это наиболее просто и логично. Остальное кривее и сложнее.
> и все довольны: не хочешь не используй и единое решение для
> всех дистрибутивов/систем инициализации.
Если инит в системе уже есть и запущен - зачем мне чтобы он висел просто так, тогда как мне придется костылить? За всех расписываться не надо.
> А проекты типа busybox могли бы включить облегченную реализацию.
А работало бы не лучше чем сейчас. Инициализация большой проги на старт каждого процесса - занимала бы времени. И куда девать результат работы? Инит есть всегда. А остальное - как повезет. Да и смысла запускать мегапрогу, чтобы очередной скрипткид тихо спустил в трэш коды возврата и вывод проги, как обычно?
> То есть вы считаете что lockup видео драйвера происходит исключительно на дискретных видиoкартах?
Я считаю что lockup видео на сервере - 100500-й приоритет. У многих серверов видео вообще может не быть. Или оно не имеет ничего общего с "видеокартой". А т.к. почти все сервера не используют видео - вероятность проблем с ним около ноля. А если чипсет или проц помереть надумал - софт не поможет.
> поймал регрессию на радеонах ведущую к lockup в kernel-4.1.
Да я такого ловил кучами. Последнее время - на SI. Но вы знаете, на большинстве серверов не будет даже вгружен модуль радеона. Да и lockup GPU клинит гyйные программы. Драйвер перестает выполнять запросы иксов и проч. Их клинит. Те кто им запросы кидал, по цепочке тоже клинятся. А ядро работает. Чтение с диска не страдает. И работа с сетью. На такую машину можно зайти по ssh, etc. Сервер вообще не заметит такое.
> При том как на дискретной, так и на чипсете.
А они даже не пытались быть надежными. Которые хоть капельку пытались - там видеовыхода нет порой :). Зато память c ECC. И стоят как два моих десктопа. А это - обычный ширпотреб.
> А как же - "У меня логика простая: система или делает то
> что должна, или уходит в ребут и восстанавливается в известное,
Так это логика беспилотной эмбедовки. Для сервера такая логика может быть, а может и не быть применима. Смотря что за сервер. Если в продакшне - может быть вариантом, на dev-машине - плохая идея. Ваши взгляды сдвинуты в сторону -dev, имхо. Для продакшна же главное - работа.
> Любое дублирование существенно повышает шансы на безотказность.
А также увеличивает цену, потребление энергии, занимаемое место, etc.
> Можно взять три ненадежных элемента - ПК, сотовый модем с gpio, RBPi
> (ждущий email с паролем для ресета). И получить достаточно безотказный удаленный ресет.
Можно. Но есть нюансы на стыке взаимодействий, а также насчет того кто и какой доступ может внепланово получить, например. И система в целом сложнее и дороже.
> продублируют, вплоть до управления со спутника.
Если удорожание оправдывается. А если нет - будет некое компромиссное решение. И да, а хотя-бы и с клацанием релюхой прямо с одноплатника иной раз.
> Всякие кocмoнавты для таких случаев берут несколько девайсов
Так и цены на это все - космические!
> ИМХО пока ядро живо, должны использоваться менее агрессивные средства (типа killall),
Ну вот прилетел мощный EMI (молния рядом шибанула, etc). Или ESD. RAM местами зaгaдилась, например - на шину навелось достаточно для переворота битов. Откуда известно что и где испорчено? При сбросе эти факторы выпадают из уравнения.
> а вачдог должен сработать только при зависании ядра либо при глухом (killall
> и рестарт не помогают) зависании служб/драйверов необходимых для удаленного управления.
Системдой можно и такое сделать в два счета. Можно просто рестартить процесс, не отсигналивший свой вачдог. Ребут безглючнее, но потеря state и больше даунтайм.
> Нет, в поставленной вами задачи - мы выносим критическую задачу на МК
> (таймер и gpio), а не критическую (веб морда) на Pi-образный девайс.
Подгон решения под ответ. То что делал Pi-образный вполне может быть ВАЖНОЙ частью задачи. И насколько это "менее" критично по мнению юзерей - варьируется в разных задачах.
> Возможно, но когда я пытался управлять насосом с выделенного ПК
ARMообразные железяки набирают аптайм... я видел около года. И как ни странно, типовая причина сброса аптайма - отключка питания по разным поводам. И при правильном подходе - сильно надежнее дешевых писюков. У большинства одноплатников btw, электролитов нет. Вспухать нечему.
> Это совершенно другая задача, и как правило менее критичная,
Очень зависит от того что за железка. Зачем юзерю например система наблюдения, которая картинку не кажет?
> чем управление всякой автоматикой. Да и она в основном решается дублированием.
Опять же - требования по надежности и последствия бывают разными. Ну а если можно подстраховаться малой ценой (e.g. вачдогование важных процессов с минимальным кодингом фичи) - я только за.
> Я просто предложил наиболее оптимальное решение для озвученной вами задачи.
При том у вас какие-то специфичные понятия об оптимальности и о том чего хотят юзеры. Не учитывающие некие факторы и игнорящие чужой опыт.
> выбирай для каждой задачи свое наиболее подходящее решение, а не одно универсальное.
Ну да. И тем не менее, у системды много настроек и поэтому он полезен много где. Не серебряная пуля, но подыграть системщику лишний раз - может.
> Все универсальное (компромиссное) будет по определению хуже специализированного
Делать ASIC под каждую задачу - долго и дорого.
> Как не крути, а что на PC что на pi-like - миллионы строк кода,
Тем не менее, этот код может работать достаточно надежно. Месяцы и даже годы. Но да, там больше потенциал для сбоев и багов и это не стоит забывать.
> ненадежная загрузка (карта памяти или винт).
Карты памяти - достаточно надежны, если от нормальных производителей и не мучать записью. Но можно и набортную флеху использовать. Даже левая фирмварь контроллера карты из уравнения выпадет. Но другие грабли добавятся (начальная прошивка станет отдельным приключением, etc).
> по железу (проще система питания, проще система охлаждения, меньше разъемов),
Главное - токи на порядок ниже и электролитов мало или нет. Одноплатники не умирают от опухания электролитов через год-два, в отличие от ПКшек.
> но ИМХО pi-like будет надежнее в 2-3 раза, а МК - на порядок или два.
Я бы сказал что может быть и на порядок: токи адекватнее, электролитов нет. Step-down на мегагерц-два (типовой IC power manager-а) доволен условно-вечной керамикой на пару десятков мкф. А в писюке проц кушает много, а керамика денег стоит. Паять СТОЛЬКО керамики всех давит жаба. А электролиты в сильноточной цепи - через пару лет дохнут. Как раз после срока гарантии.
