> Мне не понравился сам лишь подход, что в случае с sysvinit считаем
> строчки "юнит-файлов" (они же скрипты), а в случае с systemd —
> строчки системы инициализации.Хм. Знаете, у меня раж спал, я подумал, и понял, что таки да. Корректности ради код интерпретатора, возможно, стоит включить, потому как systemd инкапсулирует в себя код обработки unit-файлов. То, что интерпретатор и скрипты возможно заменить - это уже камень в сторону модульности.
>> эти 100к строчек отлаживали последние 30 лет или около того
> С таким подходом никогда нельзя разрабатывать что-то новое.
Я не совсем это имел в виду. Речь, скорее, о надёжности инструмета. Инструмент, отлаженный за несколько десятилетий, вызывает больше доверия.
А по поводу разработки нового, то я думаю так. Единственное оправдание разработки нового, это наличие задач, не решаемых старым инструментом.
> Конструктивно говорить, что в системд есть баги (и это правда),
> говорить какие именно, и тогда их будут фиксить.
Так ведь и говорят. Но фиксится далеко не всё. Разработчики уделяют куда больше внимания новым фичам, нежели исправлению существующих дефектов.
>> Раз. (см. #10 - про бинарные логи)
> все зависит от реализации. Современные информационные системы уже давно обходят проблему
> фейла физического носителя или бага в программе иначе — бекапы, copy
> on write и т.д..
Да, на самом деле я тут солидарен с Вами. В самой концепции бинарного лога нет ничего плохого. Бинарный лог может позволить хранить много дополнительной информации, которая ускорит поиск по логу и его анализ.
Собственно, речь в статье как раз о том и ведётся. Проблема в реализации бинарного лога в systemd: она не отказоустойчива. Если лог-файл был повреждён, то восстановить его невозможно. Таким образом, если у винчестер начал сбоить, то всё, логи Вы безвозвратно теряете, что может сильно помешать в диагностике неполадок.
Справедливо замечается, что мета-информацию (те же индексы и т.п.) можно было бы хранить отдельно от plain-text лога, что повысило бы отказоустойчивость journald.
> Все приложения, с которыми я сталкивался, и для которым критично логирование, имеют
> собственные системы логирования (чаще, на удаленный сервер). Но я по своему
> опыту знаю, что лет 10 назад было принято логи писать в
> структурированное хранилище (БД), потому что тяжело было что-то сделать с 20
> гб плейн текст логов. И это очень похоже на жоурналд.
Двадцатигиговый plain-text лог редко встречается на практике. Это, позвольте сказать, граничные случаи. Для граничных случаев используются специализированные решения, что само собой разумеется.
У нас в компании тоже есть для таких вот задач решения. Например есть сервис отчётов, который сохраняет всю мета-информацию о http(s)-запросах в режиме реального времени и позволяет быстро по ней произвести поиск, когда понадобится. Но это не то, чтобы лог. Это всё-таки база для весьма специфичных нужд (нужд инженеров-безопасников).
> Положительные моменты системд
> 1) я могу написать сервис, который перезапустит бинарь, если тот упадет, и
> мне не придется для этого использовать ps, grep, kill, rm myapp.pid
> и т.д.
А, много раз слышал, как systemd-шники гордятся своим watchdog-ом. Но позвольте заметить, что как минимум ещё в начале нулевых Бернштейн написал daemontools - набор утилит, которые именно тем и занимаются, что следят за тем, чтобы сервисы крутились. Уже 15 лет используем в нашей конторе для критичных мест.
> 2) я знаю, что мой сервис стартонет тогда, когда придет время
Я не понял, о чём Вы.
> Если другие системы это позволяют, ну что ж, жаль, что большинству о
> них не известно. Быть может мы бы имели систему инициализации без
> недостатков системд.
Да, это по-видимому основная проблема GNU/Linux: наличие огромного выбора. Большинство плавает среди этого выбора и не знает, куда податься.
В systemd, наверное, легче: ты выбираешь его, и за тебя уже выбрали всё, и отступить ни на шаг от этого выбора уже не удастся.
Просто это совсем не тот GNU/Linux, который мы когда-то полюбили. Это GNU/Linux, с которым мы уже ничего не сможем сделать сами, в котором мы ничего не сможем изменить.
Мне такой GNU/Linux нафиг не нужен.
>> Хотите пруфов, хотите? Их у меня много. Вся рассылка debian-russian, а ещё располагаю подборкой комментариев с opennet.
> Да я и сам могу подбросить. Иногда проще написать while true; do
> ./mydaemon; done чем разбираться, почему с системд скрипт вообще не стартует.
Во-во. Именно для того, чтобы не писать так, я использую djb daemontools. Да вот даже прямо сейчас на моей машине крутится один проприетарный игровой сервер, запущенный именно таким образом.
> Я — вовсе на фанат системд. И использую его лишь потому, что
> он поставляется по умолчанию на моем дистрибутиве.
Соболезную.
> Напоминаю, что я лишь высказал критику к статье о мифах о системд
> — не всегда весомые аргументы. Ну и я пытаюсь видеть удачные
> решения в системд.
Да, возможно, надо бы слегка освежить статью. Я благодарен Вам за свежий взгляд. Подумаю, что можно сделать для её актуализации.
