недостатки системд (повыбирал из разных веток linux.org.ru и ещё откуда-то):
-----Systemd — это, пожалуй, самая сложная init-система из существующих на данный момент.
Если подробнее, то:
Раньше в арче был BSD-Style Init. В нём последовательно запускались все демоны, указанные в rc.conf, а когда они все запустились, то стартовали и иксы.
Sysvinit остальных дистров отличается от арчевого bsdinit только тем, что вместо единого файла rc.conf используется каталог rc.d, который позволяет иметь разные списке. Но программа, которая их запускает, умеет запускать их параллельно, то есть иксы могут запуститься раньше, не дожидаясь остальных демонов. На многоядерных машинах это экономит время.
Systemd пошел дальше. Вместо простого списка сервисов, которое надо запустить, он описывает дерево запуска. Каждый его unit-файл описывает узел этого дерева. И этих unit-файлов сотни. Через unit-ы в нём описано всё, условный и безусловн
ый запуск, монтирование и проверки файловых систем, запуск и остановки и т.д. Еесли вдруг в одном из узлов дерева что-то не так, то всё поддерево перестает запускаться. Это вызывает море удовольствия в часах проведенных в попытках найти и исправить причину...
---
Поскольку юнит — это не скрипт и туда нельзя запихнуть конструкции с if и for (а такое частенько бывает нужно), то в systemd такие вещи переписывают на Си (!) и компилируют, а сам файл прописывают только запуск /usr/lib/systemd/systemd-<name>. Типичный пример: systemd-fsck-root.service.
В результате, чтобы просто узнать, что именно делает этот долбаный юнит, нужно искать среди исходников systemd (а также кучи других пакетов) нужный файл и разбираться в каше сишного кода. Которая, к слову, выглядит пострашнее любого навороченного баш-скрипта.
----
к systemd претензия в том, что он — худшее, что могли выбрать арчеводы для init-системы. Да, то, что было в арче, ужасно. Но его можно было улучшить, хотя бы добавив обработку LSB-headers для параллельного запуска. Если не хотелось изобретать свой, можно было взять готовый openrc из gentoo, старенький initrg из suse или адаптировать под себя параллельную загрузку из дебиана. Но они выбрали худший возможный вариант — сломать всё и переписать заново используя самую сложную и кривую систему из всех, что можно было выбрать.
Если бы systemd работал .— все были бы рады. Любая программа идеальна, пока она делает то, что тебе надо. В теории. Но на практике таких программ не бывает. Всегда бывает нужно изменить что-то, оптимизировать под себя настройки, добавить собственный скрипт для автозапуска или поправить один из существующих. Наконец иногда вылазят баги после апдейта, которые надо быстро поправить и работать дальше. Арчеводы, как никто другой, должны об этом знать. Но поиск багов systemd — это ужас, как его настраивать знают не многие, а отлаживать его умеют единицы.
Простой пример: если заменить /tmp на симлинк в /home/tmp, то systemd сносит крышу и система не стартует. Как это починить? Как найти причину и исправить её?
Раньше считалось, что арч хорош потому, что он KISS. Но использование вместо init-а велосипедокомбайна из (неполный список) init-демона, syslog-а, udev, cron, dbus, (x)inetd, readahead, ulatencyd, kdm/gdm/xdm, consolekit, sethostname, mount и http-сервера говорит о том, что арч больше не KISS. Какие ещё есть причины им пользоваться?
----
