> Sysvinit остальных дистров отличаетсяне отличаЕтся, а отличаЮтся.
> программа, которая их запускает, умеет запускать их параллельно
Сам инит параллельно ничего без нашлепки сверху под названием insserv (которая есть только в дебиане и Ко) запускать не умеет.
> могут запуститься раньше, не дожидаясь остальных демонов. На многоядерных машинах это
> экономит время.
> Systemd пошел дальше. Вместо простого списка сервисов, которое надо запустить, он описывает
> дерево запуска. Каждый его unit-файл описывает узел этого дерева. И этих
> unit-файлов сотни. Через unit-ы в нём описано всё, условный и безусловн
> ый запуск, монтирование и проверки файловых систем, запуск и остановки и т.д.
А как ты хотел без построения дерева зависимостей эти самые зависимости выяснить?
> Еесли вдруг в одном из узлов дерева что-то не так, то
> всё поддерево перестает запускаться. Это вызывает море удовольствия в часах проведенных
> в попытках найти и исправить причину...
Я, наверное, не буду оригинальна, однако замечу, что в логах есть эхм... скажем так, сортировка по времени. Очень сильно помогает узнавать с чего начались проблемы.
> Поскольку юнит — это не скрипт и туда нельзя запихнуть конструкции с
> if и for (а такое частенько бывает нужно), то в systemd
> такие вещи переписывают на Си (!) и компилируют, а сам файл
> прописывают только запуск /usr/lib/systemd/systemd-<name>. Типичный пример: systemd-fsck-root.service.
Если тебе так хочется свой скрипт проверки ФС, то напиши его и вызывай юнитами, кто тебе запрещает? Тебе еще и меньше кода писать придется из-за отсутствия необходимости соблюдать LSB-соглашения.
> В результате, чтобы просто узнать, что именно делает этот долбаный юнит, нужно
> искать среди исходников systemd (а также кучи других пакетов) нужный файл
> и разбираться в каше сишного кода. Которая, к слову, выглядит пострашнее
> любого навороченного баш-скрипта.
К слову, у Поттеринга и Ко код написан хорошо и понятно.
