>> Как уже отметили, речь об состоянии системы, а не о интерпретации скрипта.
> В многозадачке состояние системы всегда может меняться. Ну там часы могут например
> перевестись за счет NTP. Надо просто быть готовым к этому, в
> т.ч. и в коде.NTP — это понятно, неизбежное зло, вызванная аппаратными особенностями компьютеров. Да и вообще, это очень предсказуемая проблема, о которой в курсе каждый уважающий себя программист. А вот когда ты хочешь сделать для себя свой собственный whitelist-список устройств, а выясняется, что твоими cgroup-ами управляют извне — это уже лишний повод для проблем. Все extra features должны быть отключены по умолчанию и, желательно, должны находиться в отдельных бинариев, без которых «базовый функционал успешно функционирует».
>> Systemd/udev может изменить право доступа или имя устройства
> Может. Но для большинства девайсов это случается только при начальном добавлении или
> отключении устройства и иных нестандартных случаях. В этот момент программа в
> любом случае столкнется с исключительной ситуацией. Если там забили на ошибки
> - ССЗБ.
Опять же. Чем больше поводов для ошибки создаётся, тем больше из них приведут к fail-у в production-е. Если какой-то инструмент не нужен, то он должен быть отключен. Если, например, у меня контейнер, где все устройства статичны, то зачем мне там udev? Да и dbus там нужен чуть чаще, чем никогда. Лишь источники неполадок.
>> или создать динамически генерируемый конфиг
> В многозадачке появление файлов параллельно с работой вашей программы - штатная ситуация.
Если я правильно понял комментатора, то речь не именно про появление файла и коллизию, а про неожиданное изменение содержимого, что в свою очередь затрудняет не работу программы, а работу сисадмина, который держал у себя в голове одно содержимое, а там на самом деле уже другое.
>> - все это делает систему менее предсказуемой,
> Вы изначально не должны делать допущений о том что ваш процесс или
> скрипт единственная сущность в многозадачной системе. Фундаментальная ошибка.
Он вроде и не делал таких допущений.
>> сложнее точно сказать какие будут произведены действия в той или иной ситуации.
> Если вам всегда нужно знать все и вся с точностью до бита
> - лучше не вылезать за пределы PIC-16 и систем уровня DOS.
Всегда должна быть возможность легко диагностировать проблемы.
>> Возможно, но не думаю что разница существенна при использовании sh (ash/dash)
> Когда их будет десяток - разница может стать заметной. Да и список
> процессов замусорен лишний раз. Наф-наф-наф.
Не хотелось бы противоречить позиции Mihail-а, но всё-таки честности ради обязан сказать, что согласен: мусор вроде while true — это скорее workaround, а не production-ready решение. Как раз благодаря снижению предсказуемости :)
>> для определенных ситуаций/сервисов может быть необходима.
> Ну вот у меня этих определенных ситуаций - везде. И я хочу
> видеть ряд фич системды и на десктопах, и на серверах, и
> в эмбедовке.
Мне кажется, что это связано с неиспользованием других вещей, которые можно подцепить к тому же OpenRC
>> таймаутами, etc), не зависящей от системы инициализации.
> Система инициализации имеет очевидные плюсы:
> 1) Инит всегда запущен. Поэтому находится в нyжном месте, в нужное время,
> с нужными правами для того чтобы выступить супервизором. Не требуя по
> экземпляру на каждый процесс.
Что мешает не-init-у быть запущенным с нужными правами?
> 2) Инит всегда запущен.
Что мешает не-init-у быть всегда запущенным, после того, как init его запустит?
> Не надо делать переинициализацию процесса -> быстрее.
Какую переинициализацию процесса?
> 3) Когда процесс инита создает новый процесс для запуска сервиса, у него
> все карты на руках чтобы в этот момент расставить все параметры.
Что мешает не-init-у иметь доступ ко всему необходимому?
> Это наиболее просто и логично. Остальное кривее и сложнее.
IMHO, как раз наиболее логично и красиво, когда init — это init, а обвязка — это обвязка.
>> и все довольны: не хочешь не используй и единое решение для
>> всех дистрибутивов/систем инициализации.
> Если инит в системе уже есть и запущен - зачем мне чтобы
> он висел просто так, тогда как мне придется костылить? За всех
> расписываться не надо.
Не понял, что вы хотели сказать. Хотели сказать, что init выполняет слишком мало функций и поэтому его нужно дополнительно нагрузить? Зачем? IMHO, наоборот, он должен делать как можно меньше, а всё остальное — это отдельные штуки.
>> А проекты типа busybox могли бы включить облегченную реализацию.
> А работало бы не лучше чем сейчас. Инициализация большой проги на старт
> каждого процесса - занимала бы времени. И куда девать результат работы?
> Инит есть всегда. А остальное - как повезет.
Когда я говорил, что у меня systemd не стартовал в контейнере, один из случаев был таким:
После запуска в контейнере были толко два процесса: systemd и journalctl. Оба процесса жрали 100% CPU. Чтобы продолжить загрузку достаточно было убить через SIGKILL «journald».
> Да и смысла
> запускать мегапрогу, чтобы очередной скрипткид тихо спустил в трэш коды возврата
> и вывод проги, как обычно?
Если не хочется скрипты — можно их не использовать. Вполне можно сделать какую вам угодно обвеску вокруг init-а, который умеет работать и с unit-файлами и со всем остальным. Только пачкой отдельных процессов, которые могут легко друг без друга работать (и не требовать перекомпиляции для этого с принципиальным отключением какой-то feature). Например должна быть возможность использовать syslog-ng без journald.
>[оверквотинг удален]
> - вероятность проблем с ним около ноля. А если чипсет или
> проц помереть надумал - софт не поможет.
>> поймал регрессию на радеонах ведущую к lockup в kernel-4.1.
> Да я такого ловил кучами. Последнее время - на SI. Но вы
> знаете, на большинстве серверов не будет даже вгружен модуль радеона. Да
> и lockup GPU клинит гyйные программы. Драйвер перестает выполнять запросы иксов
> и проч. Их клинит. Те кто им запросы кидал, по цепочке
> тоже клинятся. А ядро работает. Чтение с диска не страдает. И
> работа с сетью. На такую машину можно зайти по ssh, etc.
> Сервер вообще не заметит такое.
Часто на первое время серверы делают на базе midtower-ов из-за временного недостатка денег. А там может стоять видеокарта, которая даже при обычной печате логов на экран (без framebuffer) вполне может перегреться, если что-то произошло с радиатором или вентилятором.
>> А как же - "У меня логика простая: система или делает то
>> что должна, или уходит в ребут и восстанавливается в известное,
> Так это логика беспилотной эмбедовки. Для сервера такая логика может быть, а
> может и не быть применима. Смотря что за сервер. Если в
> продакшне - может быть вариантом, на dev-машине - плохая идея. Ваши
> взгляды сдвинуты в сторону -dev, имхо. Для продакшна же главное -
> работа.
У меня есть серверы, где для production-а важнее отсутствие утечки информации, чем работоспособность. Поэтому причины отказа сервиса нужно диагностировать до перезагрузки. Если хацкер будет ломать ядро, то авто-перезагрузка даст ему неплохие возможности, ибо в случае ошибки можно будет продолжить работу.
>> ИМХО пока ядро живо, должны использоваться менее агрессивные средства (типа killall),
> Ну вот прилетел мощный EMI (молния рядом шибанула, etc). Или ESD. RAM
> местами зaгaдилась, например - на шину навелось достаточно для переворота битов.
> Откуда известно что и где испорчено? При сбросе эти факторы выпадают
> из уравнения.
Вот только до перезагрузки хотелось бы понять из-за чего возникла проблема. А после перезагрузки уже нéчего диагностировать, кроме логов.
>> Нет, в поставленной вами задачи - мы выносим критическую задачу на МК
>> (таймер и gpio), а не критическую (веб морда) на Pi-образный девайс.
> Подгон решения под ответ. То что делал Pi-образный вполне может быть ВАЖНОЙ
> частью задачи. И насколько это "менее" критично по мнению юзерей -
> варьируется в разных задачах.
>> Возможно, но когда я пытался управлять насосом с выделенного ПК
> ARMообразные железяки набирают аптайм... я видел около года. И как ни странно,
> типовая причина сброса аптайма - отключка питания по разным поводам. И
> при правильном подходе - сильно надежнее дешевых писюков. У большинства одноплатников
> btw, электролитов нет. Вспухать нечему.
[offtop]Каждый раз не сразу въезжаю, что под ARM-ообразными железками вы понимаете RPi-like, а не STM32-like (ибо тот тоже ARM).[/offtop]
>> Это совершенно другая задача, и как правило менее критичная,
> Очень зависит от того что за железка. Зачем юзерю например система наблюдения,
> которая картинку не кажет?
Если нужно в realtime казать картинку, то лучше использовать готовые системы видеонаблюдения, IMHO. Не очень понятно зачем делать своё кастомное. Единственный ответ в моей голова — работа в компании, специализирующейся на системах видеонаблюдения. Если так, то они, скорее всего, делают крупносерийные железки. А там есть смысл искать более дешёвые решения, чем RPi-like (если такие найдутся).
>> Я просто предложил наиболее оптимальное решение для озвученной вами задачи.
> При том у вас какие-то специфичные понятия об оптимальности и о том
> чего хотят юзеры. Не учитывающие некие факторы и игнорящие чужой опыт.
Мне кажется, тут этот процесс взаимный :). Для того и беседуем, чтобы понять чужой опыт.
>> выбирай для каждой задачи свое наиболее подходящее решение, а не одно универсальное.
> Ну да. И тем не менее, у системды много настроек и поэтому
> он полезен много где. Не серебряная пуля, но подыграть системщику лишний
> раз - может.
Одна из его проблем как раз в том, что у него слишком много настроек (в нём самом, а не поддержка внешнего решения, выполняющего дополнительные функции), IMHO.
>> Как не крути, а что на PC что на pi-like - миллионы строк кода,
> Тем не менее, этот код может работать достаточно надежно. Месяцы и даже
> годы. Но да, там больше потенциал для сбоев и багов и
> это не стоит забывать.
Но МК всё равно будет надёжнее, IMHO. Хватает ли ресурсов (как и в МК, так и просто человекочасов) — это конечно вопрос. Но если говорить про надёжность, то у RPi гораздо больше точек для отказа, IMHO. Хотя спроектировать собственную плату и написать прошивку — тоже те ещё задачки, даже если задача простая.
Хотелось бы понять насколько по-разному мы мыслим на примере очень простой задачки:
Допустим имеется 20 одинаковых телефонных аппаратов с какими-то неполадками (например, не рабочий экран), однако способные совершать вызовы и обеспечивать двусторонний диалог. Аппараты без кнопок быстрого набора. Стоит задача — необходимо в 20 терминалов (вандалоустойчивый компьютер) установить «кнопку экстренного телефонного вызова технической поддержки». Можно воткнуть в каждый терминал по RPi, напихать туда USB-трубок, запихать на RPi линуху с linphone-ом и при нажатии внешней кнопки вызывать тех. поддержку. А можно просто взять те полудохлые аппараты, и просто туда на базе того же stm32f0 и оптореле сделать автонабиралку номера. Потом растиражировать (распечатать ещё 19 плат и дать мартышке инструкцию по пайке). Какой вариант правильнее? И если никакой из указанных, то тогда какой?
