> что systemd не вмешается в их работу.Systemd - не искусственный интеллект. Ничего особенного со скриптами он не делает.
> Для этого нужно знать всю внутреннюю логику работы systemd, а это не 15 строк скрипта.
До того как пользоваться фичами системд - придется почитать мануал на все это. А в случае с sysv скриптами - там есть некий слой compatibility. Идея, как я понимаю, в том чтобы оно работало без изменений в скриптах или с минимумом таковых. Я правда sysv скрипты понятно где вертел и сильно это не смотрел.
А если вы из системд вызвали какой-нибудь sh - он и в африке sh. И выполнит ваш скрипт, "как обычно". Системд может вмешиваться разве что по поводу всяких там таймаутов старта/стопа и прочих лимитов на время работы. Если они есть. Ксати да, скриптеры на все это кладут. И если сервис повис на старте - "while true" не спасет. И вот такое - куда ни ткни.
А еще, если вы про экономию ресурсов - интерпретер шелла, висящий на каждый while true - ресурсов кушает. Поболее чем systemd на отслеживание процесса.
> В этом и смысл - что их можно безболезненно править и не
> боятся, что они будут вмешиваться в работу друг друга.
1) Насчет безболезненности... когда оно потом не взлетит "почему-то", а в логах ноль, а на коды возврата и прочие сообщения в stderr все забили - знаете, я без такого "счастья" у себя в системах обойдусь.
2) Насчет вмешательства - когда это вмешательство становится нужно, фича резко превращается в баг. Скрипты живут своими жизнями. Сами по себе, помимо администратора. А потом, через пару лет, начинается удивление: блин, откуда это взлетает? И по каким же блин критериям? Особенно весело если это сервер который кто-то кому-то передает на администрирование - новый админ 100% мечтал потратить недельку на разгадывание ребусов.
> Я с вами как с компетентным человеком разговариваю - а вы просто в душу ...
Уж простите что я назвал вещи своими именами, я так привык. Вещицы типа while true - хороши чтобы ими на форуме махать. Но с ними наешься "счастья" на автопилотных девайсах, серваках и прочих подобных применениях. Можно узнать много нового об ассортименте ошибок, сбоях и всех мыслимых и немыслимых вариантах как это может произойти. Вот штуки типа системд - писаны с учетом накопленного опыта факапов. И учитывают множество характерных грабель. В отличие от. И все это легко перенастраивается соотв. параметрами.
> Я и так там написал - "Сообщение в логи/на email/sms добавить по вкусу :)"
А "джамшутинг" оно не потому. А т.к. не мониторит полдюжины иных возможных failure modes и проблемных ситуаций. А они - возможны и случаются. И если самому это все кодить в скриптоте - получится жуткий макаронный монстр.
> вставьте задержку/максимальное количество итераций?
А также мониторинг таймаутов старта и стопа, придумайте свое уникальное апи для проверки живости сервиса, напишите обработку всех мыслимых ошибок, редиректы stdin-out-err... ну в общем - перепишите половину системды на соплях и скотче.
> Ну вот и приплыли: а чем он вообще занимается, если даже нельзя полноценно
> расписать реакцию при изменении состояния железа?
Он - это кто? Системд или удав? Они в принципе занимаются относительно разными вещами. Персекающимися лишь местами. Всякие сетевые вещи там запилены по минимуму. Видимо на случай когда штуки типа dhcp таки нужны, а переть что-то большое не хочется.
> Зачем он тогда в себя udev втянул?
Вообще, это 2 разные программы. Но udev таки может сигналить системде про всякие изменения железа. Поэтому насчет того что там нельзя расписать - наверное, можно. Но я не очень копался в том как удав и системд перекидываются такой информацией, мне это не требовалось как-то.
> ИМХО фичи должны быть отдельными простыми программами, слабо зависящими от конкретной
> системы инициализации.
А я хочу видеть, грубо говоря, код который сделает форк и поставит процессу запрошенные параметры. Желательно по более-менее единообразным настройкам и без долботни. А колупаться с 20 разных программ от разных авторов для всего лишь запуска сервиса - утомительно. А еще и ввинтить 20 обработок и логинга ошибок... имхо, вы так без меня развлекайтесь.
> Что мне нужно сделать в systemd для получения эквивалента "nc -ll -p
> 7777 -e /usr/libexec/sftp-server &"? Это будет проще, понятнее, надежнее?
Если у вас уже есть готовый командлайн, можно его взять да и вписать в системдшный юнит. И да, всякие & намекают на лишний фак мозга с атачем-детачем stdin/out. А знаете, у поцтера это все как-то удобно сделано. Даже всякие извращения с форком - не требуются. И настраиваемо куда и что. И по дефолту, и оверрайд по юнитам можно.
> Приведите выщ реальный пример запука сервиса и требования, и посмотрим насколько сложно
> для него написать запуск.
А смысл? Вы будете выписывать мне логинг и анализ кодов возврата? Всех вызываемых команд? Рестарт сервисов? Человеческий трекинг что и откуда взялось? Таймауты? Переназначение stdin/out/err? Посмотрите man systemd.exec, systemd.unit и systemd.service (они есть и онлайн) и подумайте что я так или иначе желаю половину этих опций в разных ситуациях. Вы правда разопретесь кодить такой макаронный монстр на скриптах? И даже почему-то думаете, что я захочу копаться в этом спагетти? Вместо того чтобы аккуратно прописать несколько параметров в конфиге? А если мне фич не хватит - вот тогда я позову скрипт. А хоть и из системды. К тому же systemd покажет - "откуда эта фигня запустилась". В sysv init это вообще не решаемо для ситуации с двойным форком. А в вот через cgroups - вполне.
Я, конечно, ценю такую дружественность от человека показавшего мне udev (он оказался любопытной штукой). Но, блин, не буду же я вас вызывать на каждый сервис который мне куда-то надо запилить. Да и мое удобство прописать несколько строк в конфиг не изменится.
> Ну и толку - сдохла видюха на сервере, получим бесконечный ребут,
Это какой-то совсем сферический юзкейс в вакууме. Для начала, в обычные сервера (и эмбедовку) нынче обычно не ставят дискретные видеокарты - 2015 год на дворе. А если сдох проц/чипсет/SoC - таки приплыли. Потребуется человек, который сменит железку.
> без возможности удаленно зайти на машину.
Это почему? Что за синтетическая ситуация? Не говоря о том что там где мне это интереснее всего - никаких "видеокарт" нет: 2015 год на дворе, дяденька. Бывают всякие нишевые юзкейсы, типа складов забитых GPU как у майнеров *коинов. Но это отдельный разговор и у них тоже таких проблем не наблюдалось, дискретный GPU обычно клинится сам и на этом все заканчивается. Сервер крутится без графики и поэтому клин 1 из GPU всем пофигу.
> или заклинивший движок только начал перегреваться и еще не сгорел ...
Autorecloser'у пофиг. Он попробует перезапустить линию в допущении что, возможно, это transient. Чаще всего так и оказывается. По поводу чего autorecloser'ы и применяют. Мало кто хочет разыскивать испарившийся дрист птички на изолятор или сгоревшую ветку, тратя на это время бригады.
> тyпой перезапуск через вачдог может сделать еще хуже.
Я обычно затачиваю железки под автопилот так, что они выходят на режим после подачи питания, не требуя внимания. Совсем. Аппаратный ресет - то же что и переподача питания. Железка должна штатно выйти на режим. Если это не так, я где-то облажался и это мой баг системной интеграции. Разрушение ФС? Можно держать rootfs readonly в большинстве случаев, или минимизировать записи (флеш к тому же запись не любит). А runtime данные хранить в tmpfs/zram/.... - требования к их non-volatile'ности, потерям и прочему весьма дико варьируются.
> Если уж серьезно относится к безотказности - то я бы сделал отдельный
> девайс для ресета, который ждет sms/email с паролем.
А кто будет проверять проверяющего? И вас не смущает, что сотовый модем - это еще несколько мегов черти-какого кода, сложный протокол, целая ОС в симкарте, и в общем то не очень надежная сеть? Не говоря о том что сотовый модем ощутимо удорожает и усложняет конструкцию. Надежность такой сбрасывалки будет врядли выше надежности вачдога. И будет много иных факторов. Ну там сотовый модем. Его ОС и вачдоги. И насколько он там выкручивается из разных ситуаций.. нуу... вот вы как раз на себе и протестируете ;].
>> поэтому ваши аргументы для меня звучат как отмазка.
> Естественно они есть, но причем здесь вачдог? Вачдог нужен когда железо/драйвер шалит,
Вачдог нужен для восстановления работы сбойнувшей системы в ожидаемое состояние, за разумное время, без внешний воздействий. Причин по которым система может сбойнуть - много. И многие из них - transient.
> дабы обнулить состояние всех регистров и стартануть все с нуля.
В общем случае вачдог обеспечивает восстановление после transient сбоев. Нечто типа autorecloser'а у электриков.
> Если завис просто софт - killall его (рестарт по вкусу), а остальные
> сервисы/приложения должны продолжать работать.
Вы знаете, задачи разные бывают. И кто и что кому там должен - очень варьируется. Можете посмотреть на mission control entity в N900 и сотоварищи как пример того как и что бывает. Когда девайс ребутается при отвале критичных компонентов, чтобы не вышло так что юзер два дня про...вал звонки из-за глюков.
> Pi-образный девайс на два порядка сложнее МК,
А связка Pi-образный + МК будет еще сложнее чем каждый по отдельности. А основы теории надежности говорят нам что так будет еще менее надежно.
> соответственно вероятность отказа на два (а может и более) порядка выше.
А с практической точки зрения - железяки показывают вполне приличную надежность.
> Для особо критичных задач МК можно продублировать - на цене это особо не скажется.
Дублируйте наздоровье. Вот только сколько МК не дублируй, а например картинку с usb-камеры на хард микроконтроллером не запишешь. А юзер врядли будет рад узнать что девайс оказывается уже 2 дня груши околачивает и ничего не наблюдает. Случаи разные бывают. И вы с вашими попытками серебряные пули втюхивать - смотритесь от "странно" до "глупо", имхо. У мк есть вполне характерные лимиты что они могут. И они ни разу не замена большим апликушным процам. А вот спихнуть часть МК-подобных операций на более крупный проц иногда можно. Если реалтаймность не жмет, апликушник всяко нужен, etc.
> Да и пока в своей практике я не видел зависшего МК, хотя
> многие работают 24/7. Чего не скажешь про ПК/роутеры/3g модемы/карты памяти.
А я могу отметить что ARMовские железяки при правильном подходе показывают неплохую надежность. Достаточную для многих применений.
ПК - сложная штука с кучей софта всех мастей и двумя газилионами процов кроме системного. Малопредсказуемы. Роутеры - там порой или нет вачдога, или китайцы его просто не включили, т.к. не умеют обслуживать. На то и китайцы. Или питальник разведен по китайски и из китайских чипов. И при заскоках питания уходит в возбуд и кормит проц таким трэшом, что проц без шансов. 3g modem - там реалтайм операционка на несколько метров, пара ядер проца минимум, а то и 4 разных проца. И еще сим-карта. Которая проц с отдельной памятью, ос, кучей приложений и даже простой ФС. Так что сказ про смс уведомления... эээ... знаете, уведомлялка или сбрасывалка по смс - менее надежна чем обороняемый ей девайс :)
> движок даже заглохнуть не успевал между перезагрузками МК :)
Ну так я не собираюсь делать систему зажигания на апликушном проце. Там наверное приличные требования к реалтайму, а сильно много мозгов как у апликушника - куда их там?
> Да но гарантировать bug free всего программного комплекса на RBPi/ПК невозможно, в
> отличии от МК.
Я вижу некое отличие между pi-like и писюком. В одноплатнике может быть 1 проц, без проприетарного кода (кроме может быть минимального boot rom, тривиального в анализе и логике работы). Это достаточно предсказуемая связка, где я контролирую все. Куда предскауемее писюшника с его BIOS, SMM и прочим крапом.
