>> что systemd не вмешается в их работу.
> Systemd - не искусственный интеллект. Ничего особенного со скриптами он не делает. Не надо быть искусственным интеллектом, чтобы вмешиваться в работу. Он может выставлять свои переменные окружения, cgroup-ы и прочие вещи, что может влиять на работу запускаемых приложений. Например один демон, который я писал, сам для себя выставляет cgroup, seccomp и прочее.
[offtop]Я вот пару дней назад столкнулся с очередной проблемой pulseaudio, который отказывался работать из-за неверно выставленной переменной DISPLAY. В качестве ошибки сообщал просто "Connection refused". Диагностировалось через strace. В общем, очередной привет от Леннарта.[/offtop]
>[оверквотинг удален]
> это. А в случае с sysv скриптами - там есть некий
> слой compatibility. Идея, как я понимаю, в том чтобы оно работало
> без изменений в скриптах или с минимумом таковых. Я правда sysv
> скрипты понятно где вертел и сильно это не смотрел.
> А если вы из системд вызвали какой-нибудь sh - он и в
> африке sh. И выполнит ваш скрипт, "как обычно". Системд может вмешиваться
> разве что по поводу всяких там таймаутов старта/стопа и прочих лимитов
> на время работы. Если они есть. Ксати да, скриптеры на все
> это кладут. И если сервис повис на старте - "while true"
> не спасет. И вот такое - куда ни ткни.
Чем OpenRC не устраивет?
> А еще, если вы про экономию ресурсов - интерпретер шелла, висящий на
> каждый while true - ресурсов кушает. Поболее чем systemd на отслеживание
> процесса.
И даже какой-то supervisor туда тоже впиливали. Хотя ниразу им не пользовалсяс.
> 2) Насчет вмешательства - когда это вмешательство становится нужно, фича резко превращается
> в баг. Скрипты живут своими жизнями. Сами по себе, помимо администратора.
> А потом, через пару лет, начинается удивление: блин, откуда это взлетает?
> И по каким же блин критериям? Особенно весело если это сервер
> который кто-то кому-то передает на администрирование - новый админ 100% мечтал
> потратить недельку на разгадывание ребусов.
Какое удивление? О чём речь? Ниразу при передаче/получении сервера у меня не было таких проблем.
Если же админ криворукий то никакие "правильные инструменты" не помогут защитить сервер от тонны нечитаемых костылей.
>> Зачем он тогда в себя udev втянул?
> Вообще, это 2 разные программы. Но udev таки может сигналить системде про
> всякие изменения железа. Поэтому насчет того что там нельзя расписать -
> наверное, можно. Но я не очень копался в том как удав
> и системд перекидываются такой информацией, мне это не требовалось как-то.
Тем ни менее насколько сложно будет пользоваться systemd, если заменить udev наместо mdev?
>> ИМХО фичи должны быть отдельными простыми программами, слабо зависящими от конкретной
>> системы инициализации.
> А я хочу видеть, грубо говоря, код который сделает форк и поставит
> процессу запрошенные параметры. Желательно по более-менее единообразным настройкам и
> без долботни. А колупаться с 20 разных программ от разных авторов
> для всего лишь запуска сервиса - утомительно. А еще и ввинтить
> 20 обработок и логинга ошибок... имхо, вы так без меня развлекайтесь.
openrc-шные скрипты минимальны по своему размеру.
А вот я хотел бы видеть рабочую систему в контейнерах с произвольными настройками. А когда внезапно systemd с journald отказывались работать из-за специфичной настройки контейнера -- это был очень неприятный момент. Слишком монструозные вещи, чтобы выполнять слишком простые задачи. Да, уже исправили, но было неприятно.
>> Ну и толку - сдохла видюха на сервере, получим бесконечный ребут,
> Это какой-то совсем сферический юзкейс в вакууме. Для начала, в обычные сервера
> (и эмбедовку) нынче обычно не ставят дискретные видеокарты - 2015 год
> на дворе. А если сдох проц/чипсет/SoC - таки приплыли. Потребуется человек,
> который сменит железку.
Хоть и не согласен, что сферический юзкеис в вакууме, но лично меня больше волнует другой случай. Если систему взламывают (и нашли дыру), что привело к зависанию системы, то перезагружать до тех пор, пока хакеры не подберут правильное смещение -- это самый плохой подход. И существует тонна других примеров, когда не нужно ничего автоматически перезапускать. Если произошла ошибка -- с ней обычно нужно сначала разобраться. Достаточно редко бывают другие ситуации.
>> или заклинивший движок только начал перегреваться и еще не сгорел ...
> Autorecloser'у пофиг. Он попробует перезапустить линию в допущении что, возможно, это transient.
> Чаще всего так и оказывается. По поводу чего autorecloser'ы и применяют.
> Мало кто хочет разыскивать испарившийся дрист птички на изолятор или сгоревшую
> ветку, тратя на это время бригады.
Не надо строить полных аналогий между электросетями и системным администрированием. Всё-таки совершенно разные вещи. Электросети не обрабатывают данные, которые могут корёжиться после каждой перезагрузки, их не взламывают и т.п.
>> тyпой перезапуск через вачдог может сделать еще хуже.
> Я обычно затачиваю железки под автопилот так, что они выходят на режим
> после подачи питания, не требуя внимания. Совсем. Аппаратный ресет - то
> же что и переподача питания. Железка должна штатно выйти на режим.
> Если это не так, я где-то облажался и это мой баг
> системной интеграции. Разрушение ФС? Можно держать rootfs readonly в большинстве случаев,
> или минимизировать записи (флеш к тому же запись не любит). А
> runtime данные хранить в tmpfs/zram/.... - требования к их non-volatile'ности, потерям
> и прочему весьма дико варьируются.
А бывают ещё задачи кроме тех, которые выполняете вы. Где, например, намного эффективнее реализовывать высокую доступность через избыточность серверов, а баги рассматривать вручную и исправлять, вместо перезапусков.
>> Если уж серьезно относится к безотказности - то я бы сделал отдельный
>> девайс для ресета, который ждет sms/email с паролем.
> А кто будет проверять проверяющего? И вас не смущает, что сотовый модем
> - это еще несколько мегов черти-какого кода, сложный протокол, целая ОС
> в симкарте, и в общем то не очень надежная сеть? Не
> говоря о том что сотовый модем ощутимо удорожает и усложняет конструкцию.
> Надежность такой сбрасывалки будет врядли выше надежности вачдога. И будет много
> иных факторов. Ну там сотовый модем. Его ОС и вачдоги. И
> насколько он там выкручивается из разных ситуаций.. нуу... вот вы как
> раз на себе и протестируете ;].
У нас был случай, когда головной узел HPC-шного кластера перезагрузился по watchdog-у тупо из-за того, что не успел ответить, так как был слишком сильно нагружен. Но забавно, что в результате перезагрузки были потеряны некоторые полезные данные, а без перезагрузки всё бы прошло само через несколько минут.
Watchdog нужен только там, где он действительно нужен.
>>> поэтому ваши аргументы для меня звучат как отмазка.
>> Естественно они есть, но причем здесь вачдог? Вачдог нужен когда железо/драйвер шалит,
> Вачдог нужен для восстановления работы сбойнувшей системы в ожидаемое состояние, за разумное
> время, без внешний воздействий. Причин по которым система может сбойнуть -
> много. И многие из них - transient.
Не надо все задачи в мире равнять на ваши.
>> дабы обнулить состояние всех регистров и стартануть все с нуля.
> В общем случае вачдог обеспечивает восстановление после transient сбоев. Нечто типа autorecloser'а
> у электриков.
Не надо электриков равнять с сисадминами.
>> Pi-образный девайс на два порядка сложнее МК,
> А связка Pi-образный + МК будет еще сложнее чем каждый по отдельности.
> А основы теории надежности говорят нам что так будет еще менее
> надежно.
Так и не надо их совмещать без необходимости.
>> соответственно вероятность отказа на два (а может и более) порядка выше.
> А с практической точки зрения - железяки показывают вполне приличную надежность.
А МК ещё более приличную. И стоят гораздо дешевле. Какой-нибудь STM32F0xx стоит порядка 50р (в текущими курсами валют) [1]. Пихать вместо него RPi без реальной необходимости -- это просто растрата.
[1] http://www.chipdip.ru/product/stm32f030f4p6/
>> Для особо критичных задач МК можно продублировать - на цене это особо не скажется.
> Дублируйте наздоровье. Вот только сколько МК не дублируй, а например картинку с
> usb-камеры на хард микроконтроллером не запишешь.
Вообще-то камеру к МК приделать можно. А сохранять на SD-карту так вообще легкотня.
Вам принципиально, чтобы камера была именно USB, а устройство хранения -- HDD? Если да, то это странно, но могу погуглить на эту тему (никогда не интересовался такими решениями и сходу не знаю как тут дела обстоят).
> А юзер врядли будет рад
> узнать что девайс оказывается уже 2 дня груши околачивает и ничего
> не наблюдает.
Кстати говоря, кроме камер бывают и другие датчики. И зачем тут винчестер? Wi-fi или ещё какой "коннективити" (как вы выражаетесь) тоже приделывается к МК. Я вот недавно закупил Wi-Fi модулей по 160р.
>> движок даже заглохнуть не успевал между перезагрузками МК :)
> Ну так я не собираюсь делать систему зажигания на апликушном проце. Там
> наверное приличные требования к реалтайму, а сильно много мозгов как у
> апликушника - куда их там?
Можно пример задачи, где не хватает МК, чтобы понять о чём конкретно сейчас речь?
И ответьте, пожалуйста на мои вопросы тут:
https://www.opennet.ru/openforum/vsluhforumID3/104497.html#170
