> NTP — это понятно, неизбежное зло, вызванная аппаратными особенностями компьютеров.Это не аппаратные особенности компьютеров, это следствие многозадачности ОС. А факапы - следствие того что некоторые люди мнят что они в системе одни и никто не может часы перевести. А это не так. И это касается всех аспектов работы многозадачки.
> Да и вообще, это очень предсказуемая проблема, о которой в курсе
> каждый уважающий себя программист.
Программист или понимает что это многозадачка, состояние которой меняется в множестве закоулков помимо него, или нет. Чего бы вдруг он поймет прo NTP, но прощелкает с открытием файлов или правами - не понятно.
> А вот когда ты хочешь сделать для себя свой собственный whitelist-список
> устройств, а выясняется, что твоими cgroup-ами управляют извне — это
> уже лишний повод для проблем.
А как управление cgroups вообще пересекается с белым списком устройств?
> Все extra features должны быть отключены по умолчанию и, желательно, должны
> находиться в отдельных бинариев, без которых «базовый функционал успешно функционирует».
Ну вот и отключайте себе sysfs и procfs в ядре, наздоровье. Вон тут гражданин проверил что без них можно обойтись, если очень захотеть.
> Опять же. Чем больше поводов для ошибки создаётся, тем больше из них
> приведут к fail-у в production-е.
Теоретически это так. Практически - все несколько сложнее. Решение задачи ограничено по времени, деньгам и ресурсам и поэтому доводить все до максимально оптимзированного ASIC с минимально-возможным числом транзисторов у меня может и не быть ресурсов и времени и это может быть нецелесообразно по стоимости. Поэтому сказать что systemd мне не требуется - я не готов.
> Если какой-то инструмент не нужен, то он должен быть отключен.
Если на то пошло - можно обойтись без библиотек. И без ядра. Написать все самому, в фирмваре делающей прямой доступ к железу, и телемаркет. Хотя лучше сразу ASIC максимально оптимизированный запилить. Но вот правда есть нюансы.
> Если, например, у меня контейнер, где все устройства статичны, то зачем мне там udev?
В именно контейнере - может быть и ни к чему. С другой стороны, по логике вещей в контейнер должно быть можно пробросить девайсы и не только статично, а то что ваш юзкейс принципально лучше других или наиболее типовой - бабушка надвое сказала.
> Да и dbus там нужен чуть чаще, чем никогда. Лишь источники неполадок.
Я даже и не могу вспомнить на моей памяти когда d-bus у меня неполадки хоть в чем-то вызывал.
> и коллизию, а про неожиданное изменение содержимого, что в свою очередь
> затрудняет не работу программы, а работу сисадмина, который держал у себя
> в голове одно содержимое, а там на самом деле уже другое.
Админ имхо на себя много брал, делая такие допущения в многозадачке. С такими запросами - в MSDOS, имхо.
> Он вроде и не делал таких допущений.
Тогда я не понимаю что ему не нравится. Изменение файлов по ходу работы системы - обычное дело для многозадачки.
> Всегда должна быть возможность легко диагностировать проблемы.
И кроме всего прочего sysv init этому совсем не соответствовал: там вообще нет никакого boot time дебага, логинг по принципу "насколько не лень майнтайнеру", отсутствие реакции на коды возврата в большинстве случаев и прочая. И потенциально куски сложной логики в неожиданных местах.
> Не хотелось бы противоречить позиции Mihail-а, но всё-таки честности
> ради обязан сказать, что согласен: мусор вроде while true — это скорее workaround,
Это вообще источник кучи проблем. А поттеринг обрабатывает массу проблемных ситуаций. Иногда случающихся в продакшновых системах. И совсем не радующих потом.
> которые можно подцепить к тому же OpenRC
Не вижу какие из моих проблем OpenRC вообще решал бы и делал это лучше чем конкуренты типа системды. И куча скриптятины, писаной левой пяткой по укурке - довольно сильно снижает предсказуемость системы, имхо.
> Что мешает не-init-у быть запущенным с нужными правами?
То что все это - отдельные действия. Требующие весьма отдельной обработки и аккуратности, а потом еще и сброса прав. Потому как фигарить под полновесным рутом в программе как-то ну совсем не комильфо. И в результате это еще туева хуча системного кода. В каждой проге.
ИМХО лучше выгрузить это в systemd и потом реюзать его код. Из всех программ. Парой строк конфига.
> Что мешает не-init-у быть всегда запущенным, после того, как init его запустит?
Наверное то, что если он помрет - супервизить его должен был кто-нибудь другой. Инит отлично годится на эту роль: всегда есть, имеет нужные права, знает что запускает.
> Какую переинициализацию процесса?
Ну там форки лишние, etc.
> Что мешает не-init-у иметь доступ ко всему необходимому?
То что на все это надо дофига прав, эти права в run time обычно не требуются, а кодинг половины системной механики по деланию всего этого и сброса прав - очень отдельное развлечение, которым я не хочу в каждой первой программе заниматься.
> IMHO, как раз наиболее логично и красиво, когда init — это init,
> а обвязка — это обвязка.
А на мой вкус - кое-кто игнорил кучу long-standing проблем программирования и администрирования. И потом подобным кадрам довольно жестко объяснили что они в этом неправы.
> Не понял, что вы хотели сказать. Хотели сказать, что init выполняет слишком
> мало функций и поэтому его нужно дополнительно нагрузить? Зачем?
Потому что он висит с полными правами. Всегда. И порождает остальные процессы. И поэтому ему проще и логичнее всего делать вещи типа супервизинга процессов. Даже sysv init это умеет малость. Но в таком виде, что толку с этого - ноль.
> IMHO, наоборот, он должен делать как можно меньше, а всё остальное — это
> отдельные штуки.
Я как админ и програмер на изветсном месте вертел перспективу кодить или скриптить базовые системные операции на каждую первую оказию.
> После запуска в контейнере были толко два процесса: systemd и journalctl. Оба
> процесса жрали 100% CPU. Чтобы продолжить загрузку достаточно было убить через SIGKILL «journald».
Ну как бы баг. И с технической точки зрения:
- Systemd сам по себе может ловить как раз взвис сервиса на старте и проверять фактическую живость. Если это не было настроено - это к админу. А если не сработало - поцтеру в багтрекер.
- Взвис journalctl не является правильным поведением, имхо. Это некий bug.
Но знаете, вон например у дебианщиков - скрипты не могли нормально остановить нжинкс одно время. Вообще заваливая деинсталл пакета. Но я что-то не помню жутких воплей что скрипты - это фи.
> Если не хочется скрипты — можно их не использовать. Вполне можно сделать
> какую вам угодно обвеску вокруг init-а,
Ну вот в systemd как-то так и есть: я буду звать скрипты только когда это реально требуется.
> Например должна быть возможность использовать syslog-ng без journald.
А у вас разве кто-то занимал? Или с чего они вдруг вам "должны"?
> логов на экран (без framebuffer) вполне может перегреться, если что-то произошло
> с радиатором или вентилятором.
ИМХО это синтетическая и кривая ситуация и тут надо не софту предъявлять, а тем кто таким занимается. Ну ставили бы ARMовскую платку за тридцать баксов, она при всем желании не перегреется и без вентиля. В миди-тауэре можно целый кластер собрать. А то что кто-то набрал на помойке глючных писюков - его проблемы. Желать чего-то от глючного железа вообще оксюморон.
> У меня есть серверы, где для production-а важнее отсутствие утечки информации, чем
> работоспособность. Поэтому причины отказа сервиса нужно диагностировать до перезагрузки.
А у многих других людей другие приоритеты и случаи. ИМХО дефолты должны делаться так чтобы покрывать наиболее типовые юзкейсы.
> Если хацкер будет ломать ядро, то авто-перезагрузка даст ему неплохие возможности,
> ибо в случае ошибки можно будет продолжить работу.
Потенциально есть такие грабли. Но что и где приоритетнее... вот у меня на железке сети может не быть совсем. И хацкеров. А вот зависон - это грабли.
> Вот только до перезагрузки хотелось бы понять из-за чего возникла проблема. А
> после перезагрузки уже нéчего диагностировать, кроме логов.
Можно попробовать core dump собирать. Но коредампы в продакшне - еще одна мина замедленного действия.
> вы понимаете RPi-like, а не STM32-like (ибо тот тоже ARM).[/offtop]
Ну да. В основном штуки на allwinner. Несмотря на то что там автомобиль собирают по ходу гонки, core parts линя обычно оправдывают ожидания и не подводят.
На самом деле я видел всего 2 deadlock за все время. Один - в вендырском ядре 3.4, эзернет. Это known issue для тех кто в теме и одна из причн антипатий к вендырским SDK. Китайские дрова - гуано. Второй был судя по всему race condition когда у usb-девайса были проблемы с кабелем и девайс подключался-отключался с максимальной скоростью. В конце концов, через 10 минут странностей ядро Linux таки поймало deadlock. Через 10 секунд вачдог все это срубил, подтвердив что я немного научился готовить этих кошек.
> Если нужно в realtime казать картинку, то лучше использовать готовые системы видеонаблюдения,
Они или не умеют анонсы в желаемом виде, или льют видео на хрен знает какие сервисы, и вообще достаточно дубовые и дорогие штуки. Мне они не нравятся.
> моей голова — работа в компании, специализирующейся на системах видеонаблюдения.
На самом деле конкретно вот такие хотелки - больше для себя. В перспективе я научусь делать нечто типа core для умного дома. Кроме всего прочего и потому, что мне самому надо несколько юнитов такого добра. Быть сапожником без сапог надоело, а найти опенсорсное и не западлоидизированное, по симпатичной цене... ну я не в курсе таких опций.
> есть смысл искать более дешёвые решения, чем RPi-like (если такие найдутся).
Сильно дешевле - некуда. При малейшем намеке на конективити это всяко SoC с линухом. Да и интерфейсы типа два притопа, три прихлопа - лишь Зенкову нравятся. А я не фанат такого. И остальные юзеры тоже.
> Для того и беседуем, чтобы понять чужой опыт.
Вообще, да. Но многие ваши сценарии кажутся мне странными.
> Одна из его проблем как раз в том, что у него слишком много настроек
С другой стороны, все это более-менее оттестирует толпа народа. И это обезглючат. В отличие от глюченных скриптов и черти-каких конфигураций, работающих абы как.
> (в нём самом, а не поддержка внешнего решения, выполняющего
> дополнительные функции), IMHO.
Обезглючить массово применяемое решение проще чем 100500 кастомных конфиг. Поэтому я могу поверить что системд будет относительно стабильным. А вот абы какие кастомные конфиги из скриптов, соплей и скотча, где часто не проверяют не то что таймауты но и коды возврата...
> Но МК всё равно будет надёжнее, IMHO.
Зависит от конкреитки. Но вообще в целом потенциал к этому у МК есть.
> если говорить про надёжность, то у RPi гораздо больше точек для отказа, IMHO.
Но сильно меньше чем в писюке. И я не люблю Pi - они неважные инженеры. Но есть много иных модулей и одноплатников.
> Хотя спроектировать собственную плату и написать прошивку — тоже
> те ещё задачки, даже если задача простая.
Пойнт модулей и одноплатников как раз в том что сам такую штуку проектировать слегка задолбаешься, а когда грабли обпрыгали другие - уже ничего так, нормальненько :)
Про телефоны - относительно длинно, см part 2.
