Исправление siraenuhlaalu, (текущая версия) :
Ведь очевидно, что реализовывать сложную систему загрузки с логами в бинарном виде и прочее - излишняя трата ресурсов.
Она не сложная, в том-то и дело. Логи у тебя получаются «по дефолту», потому что systemd не закрывает дескрипторы stdout/err запускаемых процессов. Это делается «по умолчанию», вместо того, чтобы реализовывать это в коде сервиса или делать перенаправление в скрипте. При этом, никто не мешает писать отдельные логи в файлы или syslog. Абсолютно так же у тебя «по дефолту» получается отслеживание статуса запускаемых процессов.
Если же сравнивать с sysvinit, то сам по себе бинарник init сделан относительно нормально для того времени, когда его разрабатывали: логика «прочитай конфиг из /etc/inittab, запусти параллельно то, что описано для данного ранлевела» вполне себе нормальная. Собственно, ничего не мешает запускать сервисы прямо из /etc/inittab, кроме того, что у них могут быть зависимости друг от друга, что ставит крест на этом подходе на современных системах. Поэтому из inittab сейчас запускаются только getty, что, в том числе, позволяет отследить статус процесса и перезапускать их в случае необходимости. Для всего остального используется один дочерный процесс /etc/rc.d/rc, который запускает сервисы последовательно, при этом, не трэкая их состояние никоим образом. А вот потом, чтобы трэкать состояние сервиса, придумывается ещё больше костылей: кто-то делает unix-сокет для управление через *ctl, кто-то пишет в pid-файл из сервиса, кто-то вообще по регэкспу ищет в выводе ps.
id:3:initdefault:
si::sysinit:/etc/rc.d/rc.sysinit # запустим это в самом начале (это обычный скрипт, исполняемый последовательно, пусть будет, жрать не просит)
~~:S:wait:/sbin/sulogin # у нас что-то сломалось? запустим sulogin (отличное решение, почему бы и нет?)
1:2345:respawn:/sbin/mingetty --noclear tty1 # запускаем mingetty на каждый терминал, запуск происходит параллельно (отличное решение, почему бы и нет?)
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
l0:0:wait:/etc/rc.d/rc 0 # а вот здесь начинаются костыли
...
l3:3:wait:/etc/rc.d/rc 3
...
Понятное дело, что этот ахтунг рано или поздно должны были зарефакторить. Лично я бы скорее всего начал с того, чтобы заставить init применять ранлевелы последовательно, используя ранлевел как индикатор того, что сервис A должен быть запущен до сервиса Б, затем добавил возможность включать куски конфига из других файлов и мне скорее всего этого бы хватило. в systemd же пошли несколько дальше, переименовав ранлевелы в таргеты и добавив возможность указывать зависимости не от ранлевела, а от конкретного юнита.
Исходная версия siraenuhlaalu, :
Ведь очевидно, что реализовывать сложную систему загрузки с логами в бинарном виде и прочее - излишняя трата ресурсов. Она не сложная, в том-то и дело. Логи у тебя получаются «по дефолту», потому что systemd не закрывает дескрипторы stdout/err запускаемых процессов. Просто это делается «по умолчанию», вместо того, чтобы реализовывать это в коде сервиса или делать перенаправление в скрипте. При этом, никто не мешает писать отдельные логи в файлы или syslog. Абсолютно так же у тебя «по дефолту» получается отслеживание статуса запускаемых процессов.
Если же сравнивать с sysvinit, то сам по себе бинарник init сделан относительно нормально для того времени, когда его разрабатывали: логика «прочитай конфиг из /etc/inittab, запусти параллельно то, что описано для данного ранлевела» вполне себе нормальная. Собственно, ничего не мешает запускать сервисы прямо из /etc/inittab, кроме того, что у них могут быть зависимости друг от друга, что ставит крест на этом подходе на современных системах. Поэтому из inittab сейчас запускаются только getty, что, в том числе, позволяет отследить статус процесса и перезапускать их в случае необходимости. Для всего остального используется один дочерный процесс /etc/rc.d/rc, который запускает сервисы последовательно, при этом, не трэкая их состояние никоим образом. А вот потом, чтобы трэкать состояние сервиса, придумывается ещё больше костылей: кто-то делает unix-сокет для управление через *ctl, кто-то пишет в pid-файл из сервиса, кто-то вообще по регэкспу ищет в выводе ps.
id:3:initdefault:
si::sysinit:/etc/rc.d/rc.sysinit # запустим это в самом начале (это обычный скрипт, исполняемый последовательно, пусть будет, жрать не просит)
~~:S:wait:/sbin/sulogin # у нас что-то сломалось? запустим sulogin (отличное решение, почему бы и нет?)
1:2345:respawn:/sbin/mingetty --noclear tty1 # запускаем mingetty на каждый терминал, запуск происходит параллельно (отличное решение, почему бы и нет?)
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
l0:0:wait:/etc/rc.d/rc 0 # а вот здесь начинаются костыли
...
l3:3:wait:/etc/rc.d/rc 3
...
Понятное дело, что этот ахтунг рано или поздно должны были зарефакторить. Лично я бы скорее всего начал с того, чтобы заставить init применять ранлевелы последовательно, используя ранлевел как индикатор того, что сервис A должен быть запущен до сервиса Б, затем добавил возможность включать куски конфига из других файлов и мне скорее всего этого бы хватило. в systemd же пошли несколько дальше, переименовав ранлевелы в таргеты и добавив возможность указывать зависимости не от ранлевела, а от конкретного юнита.