> Почему же именно bash?цепочки инита
kernel -> (sysvinit -> bash + grep + ps + kill + ...) -> target binary
kernel -> systemd -> target binary
В первом случае может быть другой шел, да. Но не суть. Мне не понравился сам лишь подход, что в случае с sysvinit считаем строчки "юнит-файлов" (они же скрипты), а в случае с systemd — строчки системы инициализации.
> эти 100к строчек отлаживали последние 30 лет или около того
С таким подходом никогда нельзя разрабатывать что-то новое. Говорить, что системд плохая, потому что ее конкурент уже 30 лет работает — это, мне кажется, неконструктивно. Конструктивно говорить, что в системд есть баги (и это правда), говорить какие именно, и тогда их будут фиксить.
> Раз. (см. #10 - про бинарные логи)
все зависит от реализации. Современные информационные системы уже давно обходят проблему фейла физического носителя или бага в программе иначе — бекапы, copy on write и т.д..
На самом деле сильных аргументов у меня нету. Я не очень понимаю проблему.
Все приложения, с которыми я сталкивался, и для которым критично логирование, имеют собственные системы логирования (чаще, на удаленный сервер). Но я по своему опыту знаю, что лет 10 назад было принято логи писать в структурированное хранилище (БД), потому что тяжело было что-то сделать с 20 гб плейн текст логов. И это очень похоже на жоурналд.
Сейчас — время облаков, все, обычно, пишется в системы хранения логов, например, на основе эластиксерч. И там тоже структурированный формат. Есть поле месседж, где фритекст, есть поле хост, есть поле ип, есть поле дата, и т.д.. И эти логи тоже нельзя прочитать с помощью вима. И это тоже очень похоже на жоурналд.
Но, повторюсь, я, возможно, далек от проблемы.
> Так ведь в том и дело, что эта инициатива в дебиановском sysvinit уже имелась на момент создания systemd. Ко скриптам инициализации были добавлены LSB-заголовки, в которых прописали зависимости. Sysvinit стартовал демоны параллельно и разруливал зависимости.
Вот об этом я не знал.
Положительные моменты системд
1) я могу написать сервис, который перезапустит бинарь, если тот упадет, и мне не придется для этого использовать ps, grep, kill, rm myapp.pid и т.д.
2) я знаю, что мой сервис стартонет тогда, когда придет время
Если другие системы это позволяют, ну что ж, жаль, что большинству о них не известно. Быть может мы бы имели систему инициализации без недостатков системд.
> Хотите пруфов, хотите? Их у меня много. Вся рассылка debian-russian, а ещё располагаю подборкой комментариев с opennet.
Да я и сам могу подбросить. Иногда проще написать while true; do ./mydaemon; done чем разбираться, почему с системд скрипт вообще не стартует. Или почему, при умирании не отрабатывает очистка каких-нибудь ресурсов. Или... Да много я провел времени, чертыхаясь. То диски не отмонтируются. То пользовательская сессия на стартует. За это время можно было бы сотни две баш скриптов написать.
Я — вовсе на фанат системд. И использую его лишь потому, что он поставляется по умолчанию на моем дистрибутиве.
Напоминаю, что я лишь высказал критику к статье о мифах о системд — не всегда весомые аргументы. Ну и я пытаюсь видеть удачные решения в системд.
