Finit - это очередная система инициализации для linux.
В эпоху победившего systemd говорить о других системах да и вообще заострять внимание именно на системе инициализации как таковой уже не модно.
Но тем не менее, как то раз мне на глаза попалась новость о выпуске очередной версии этой системы. Тогда я лишь мЕльком глянул, что это за система и забыл.
Некоторое время назад эта тема всплыла снова. И тут я решил присмотреться к finit - собственно, что это и с чем его едят.
В тексте проекта написано, что автор вдохновлялся и вобщем-то содрал (чего уж там таить) довольно много наработок fast init-а. Проекта, автор которого занимался реверс-инжинирингом системы инициализации в первых eeepc.
Но, как бы то ни было, а результат получился... очень напоминающий классический system v init. Но на стероидах и подкостыленный. Стероиды напоминают идеи systemd, то есть имеется подпорка под инициализацию иксов, свои getty и по мелочи разные вещи.
Собственно, feature creep - это то, что мне не понравилось.
Что могло бы стать киллер-фичей? Зависимости между сервисами. В документации декларировано, что сервисы могут стартовать в зависимости от неких условий, в том числе по условию наличия pid-файлов и юзерских событий. Вроде звучит круто. Но ведь есть подвох? Должен быть подвох 😊
И он действительно есть - pid-файл должен создаваться сервисом. Мало того, несмотря на то, что сервис запускается, факт запуска сервиса не является событием. Конечно, есть генератор событий, то есть перед запуском сервиса в foreground-е можно бы триггерить такое событие, а все зависящие сервисы запускать с паузой например в 1-3 секунды, "чтобы уж точно". Но во-первых - не точно, а во-вторых, если я руками сервис остановлю, то ивент об остановке сервиса не будет сгенерён.
Как это можно было бы обойти? Хуками на пред-запуск, перезапуск, остановку и аварийное завершение сервиса. Но таких хуков в finit вообще нету. А вот, например, в openrc с событиями всё хорошо - то есть там вполне можно построить иерархию зависимостей сервисов. И, например, тогда, при запуске сервиса, который зависит от других сервисов, эти сервисы будут автоматом запускаться. А при останве сервиса, от которого зависят другие сервисы, эти все сервисы будут тоже автоматически останавливаться.
В результате мы имеем довольно бесполезный init, мало чем отличающийся от того же runit-а по своей сути. Разве что oneshot-скрипты поддерживаются из коробки (но формально такие же one-shot-ы можно накостылить и в runit-е. Например, через таски, которые никогда не завершаются (которые последней инструкцией например вызывают cat /dev/null или делают while [ true ]; do sleep большое_число; done, насколько помню sleep infinity в баше для 32 бит - это 68 лет а для 64 бит - это 10 ^ 11 лет).
Собственно, исключая синтаксис конфигов, finit от runit-а отличается только количеством форков в процессе запуска системы + синтаксисом этих самых конфигов.
Учитывая, что bash - это не самый эффективный и быстрый shell, то по большому счёту многие моменты оптимизации процесса подготовки системы к запуску или завершению работы сводятся к тому, чтобы запускать стартовые скрипты из-под например ash или dash, которые быстрее, имеют меньше зависимостей от системных библиотек, а также уменьшить количество вызываемых grep awk sed в стартовых скриптах.