У меня была заметка про случай с systemd, но в блоге я её не публиковал. Кроме того, за последующие годы накопились другие случаи из практики. Поэтому решил собрать этот материал в одном месте.

Для начала, оригинальное сообщение из 2020 года.

## Удаление IPC при logout

Привет!

До последнего относился к деятельности Поттеринга с пониманием. Прогресс дело такое. Linux давно уже сложная система, systemd неизбежен -- думал я.

Пока не коснулось моей работы. Несколько лет у нас периодически падала сборка, в момент работы fakeroot. Отлаживали faked, пытались разнести во времени сборки -- результата не было. Наконец, когда за одну ночь сборка упала 5 раз я не выдержал и попытался в очередной раз найти причину.

Помог гугл. Оказалось, что systemd стирает объекты IPC при log-out пользователя из системы. А на систему сборки периодически ломились наши боты, проверяя статус сборки итд.

В общем, RemoveIPC=no в /etc/systemd/logind.conf помог. По крайней мере, три дня уже всё чисто.

Конечно, ошибаются все. Но в данном случае это не ошибка, а осознанное убивание Unix. Ситуация наглядно иллюстрирует тот факт, что когда какой-то Unix компонент занимается не своим делом, найти проблему очень и очень сложно.

Как вообще могло придти в голову стирать что-то там при logout? Удивительно, что /tmp не затирается...

В общем, признаюсь себе честно -- Linux больше не система моей мечты. Я разочарован и удручён. Похоже, Plan9 и BSD системы -- это мой удел на старости лет. Linux -- система для выполнения утилитарных вещей и это моя работа. Но сказать, что мне нравится выбранный курс развития -- категорически не могу. Linux стал слишком "взрослым". Sad but true...

## Удаление "временных файлов"

> "Удивительно, что /tmp не затирается..."

Как наивен я был!

Да, зачистка данных во время работы системы это действительно архитектурное решение, которое целенаправленно продвигается разработчиком. И следующий случай это подтверждает.

Разрабатываемая embeded-система работала около месяца, а потом у неё отваливалась подсистема конфигурации. Когда это произошло во второй раз я сразу подумал о systemd. Ведь работало это удаление "как часы". Заглянул в /etc/systemd/tmpfiles.d и... чего только там нет! Я не помню что именно он стирал, но сам факт, что на работающей автономно системе какой-то компонент начинает вдруг стирать чужие файлы (например, в /var/tmp) по ему одному ведомой причине -- это просто за гранью добра и зла.

Если вы по прежнему считаете, что это "правильное направление" (ведь речь идёт о "временных" файлах) то... вот: https://www.opennet.ru/opennews/art.shtml?num=61403

> ... опция "--purge" удаляет все файлы и каталоги, созданные через настройки tmpfiles.d, но название "tmpfiles" в названии утилиты вводило в заблуждение и создавало впечатление, что удаление касается только временных файлов. При этом настройки tmpfiles.d не ограничиваются временными файлами и также используются для автоматического создания несуществующих каталогов с данными. В частности, удаление содержимого домашних каталогов объясняется тем, что при помощи файла "/usr/lib/tmpfiles.d/home.conf" создавался раздел "/home" и, соответственно, команда "systemd-tmpfiles --purge" приводила к его удалению.

То-есть, tmpfiles это уже не временные файлы. :)

Кстати, в 257 приладили "костыль" чтобы сгладить проявления своего архитектурного пути: https://www.opennet.ru/opennews/art.shtml?num=62380

> В systemd-tmpfiles во избежание ошибочного удаления не тех файлов опция "--purge" теперь применяется только к настройкам в tmpfiles.d/, для которых явно выставлен флаг "$"


## Встроенные fallback-сервера

Следующая проблема. По умолчанию в systemd встроены адреса fallback dns и ntp серверов. То есть, если вы ничего не настраивали система всё равно будет долбиться на какие-то сервера "из коробки". Казалось бы, должна быть опция отключить это. И действительно, в манах есть кое-что на эту тему. В том числе описание приоритетов каталогов systemd с конфигурационными файлами. Я сейчас не помню деталей, но полностью "выжечь" обращение к внешним серверам зашитым где-то внутри мне удалось только патчем на код. После нескольких безуспешных попыток решить это конфигурационными файлами. Вещь в себе.

## Старт с ro-раздела

systemd не рассчитан на старт с ro-раздела. В systemd есть код, который адаптирован к этой ситуации (например, делает bind /etc/machine-id на файл в /run), но в целом - он не готов. Причём просто так поменять-задать местоположение rw-данных мы не можем -- все эти "/etc" зашиты прямо в код. В итоге в embeded-среде принят подход (рекомендован Поттерингом) с монтированием rw-оверлея /etc/ в initramfs _до_ запуска systemd, что снова выглядит дикой дичью. Неужели сложно было параметризовать эти вещи с самого начала? Снова патчим systemd...

## Баги и эффект чёрного ящика

Баги в реализации. Я встречался с некоторыми багами, которые ведут в .c часть. Например, некорректное слежение за состоянием интерфейса по netlink (код не был рассчитан на "нестандартную ситуацию" и принимал один тип сообщений за другой). Не помню уже как именно это проявлялось, скорее всего что-то связанное с dns серверами и маршрутами полученными по dhcp. Понятно, что "C" код для администратора это чёрный ящик и исправить что-то "на месте" практически нереально. В отличие от систем, где каждый компонент может быть заменён и их взаимодействие прозрачно. Здесь же есть "вещи в себе" которые или работают или нет.

## Заключение

Не могу сказать что в systemd присутствует только плохое. Когда компоненты работают без ошибок (и сюрпризов!), в целом, пользоваться этим удобно. Сложность "запрятана" в сам systemd. Мне в целом нравится тот же journald -- возможностью выборки по unit, а не только по facility/priority.

Вообще, systemd должен был появиться и это естественный путь развития для Linux. Жаль только что спроектирован он .. "напролом". В нём нет элегантности, "хакерской" изящности и гибкости. Предлагаются "готовые" решения, которые могут подойти и тогда всё хорошо (если нет багов). Или не подойти -- и тогда делай что хочешь. :) Ну а про то, что он слишком много на себя берёт я уже написал.

Тем не менее, не зависимо от того любите ли вы systemd или нет, если вы работаете с Linux - вам придётся с ним познакомиться (рано или поздно).

Читая пост возник только один вопрос: а почему systemd вообще используется в embedded? Каких-то своих узкоспециализированных решений нет?

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

doesnm> Читая пост возник только один вопрос: а почему systemd вообще используется в embedded? Каких-то своих узкоспециализированных решений нет?

Смотря что понимать под embedded. Ведь часто это "обычный линукс" работающий на спец. железе. И там тоже нужен тот же udev, например. Который давно есть часть systemd. :) Вообще, systemd постепенно всё глубже проникает в экосистему и с определённого момента проще расслабиться и плыть в струе мейнстрима... ;)

doesnm> Линукс-то обычный, но у меня ассоциации embedded с очень слабым железом и поэтому systemd кажется немного пушкой по воробьям. Да и вроде как есть тот же eudev

Слабое железо тоже уже давно не слабое... Ну взять хотя бы домашние роутеры. Нормальное там железо. И с systemd система будет быстрее скорее всего загружаться. :) Так что это даже довод ЗА systemd как это не парадоксально. eudev как не крути вещь вторичная. А так, конечно, можно. Но в целом, можно и systemd в какой-то части использовать. Вопрос - что выбрать. В том же https://buildroot.org/ systemd есть как опция.