Это из области религии. Им кто-то сказал, что системд — неправославно, ну а дальше все как обычно абама черный член вытираны линупс деды песали лапшу и мы будем рачнаш
наверно потому, что у некоторых опытных программистов выработался инстинкт самосохранения от вырывания волос на жопе, ковыряясь в монструозном неподдерживаемом говне через несколько лет вперед
этакий наметанный глаз на хорошую архитектуру, которой системд, к сожалению, не обладает
За то, что его любят тупорылые вендузятники неспособные осилить какой-нибудь язычок программирования. В общем, «если сделать систему которой сможет пользоваться вендузятник, то только вендузятник захочет ей пользоваться». Потому и...
Я тут, кстати, обнаружил фишку systemd by desing (хотя, больше я ее не проверял, так что мб просто так звезды сложились).
Если на dbus system шине вызвать stack overflow, то systemd уходит в астрал. Нет, ну он пытается реагировать на действия, но, например, перезагрузить компьютер не получится - он виснет где то в конце работы. Ну и да, никакой запрос к нему не отправишь :( Кстати, при этом демон не падает, почему то.
А вот если segfault вызван, например, обращением к неициализированному указателю, то тут ожидаемое поведение - демон просто упадет
/usr на отдельном разделе можно, если он монтируется до инита (например, из initramfs)
/usr на отдельном разделе можно и не монтировать до инита, просто будут рандомные фейлы в куче софта (например, в udev, в т. ч. до слияния). И сам systemd на работу в таком режиме не особо тестируют, потому что нет причин не пользоваться п. 1.
Пишем собственный интерфейс для dbus, у которого есть метод, вызывающий переполнение стека (e.g. просто возвращающий сам себя). Запускаем интерфейс на системную шину и вызываем данный метод.
Я могу напридумать задач с которыми эти варианты не пройдут. Это будет что-то очень специфичное и не очень нужное, но есть же те кому вдруг понадобится.
Ну например захочу /usr на софтварном райде и dm-crypt'е по какой-то причине.
Я не особо силен в чисто архитектурных вещах, но, как мне сдается, dbus - штука параллельная systemd (или их уже связали намертво?). Подобный вызов в свою очередь кладет dbus шину, через которую общается systemd, что приводит к невозможности управления чем либо на уровне инита.
Ну. Это проблема в dbus, я бы сказал. Проблема совершенно точно не архитектурная, потому что всегда можно сделать приватную фоллбэк-шину (она там даже уже есть, только ручной выбор между приватной и основной невозможен).