постойте, все три продукта запускают баш (это /bin/sh на упомянутом выше редхате). т.е. игнорировать уязвимости баша нельзя. и ни один из них не состоит в одной категории с системд-проектом(ваш список уязвимостей не ограничен системд-пид1). системд-проект это базовая система, в одной категории с ним стоят наборы из десятков программ, сдобренных кривыми скриптами.
если опасения это «тащить всю функциональность в один гит репо», то вам надо посмотреть на модель разработки фрибсд(той самой, которая юникс, о потором забыл системд) и ужаснуться. это про системд-проект.
а основным мотиватором системд-пид1 был лончд из макоси(тоже юникс, кстати) — на макось равняться православнее, чем на винды?
в системд есть встроенная поддержка неймспейсов. плюс с ним идет systemd-nspawn, так что докер необязателен. и вопрос исключения сигрупп ради портабельности никак не обработан
системд идет в стандартной поставке мейнстрим дистров. если у вас лфс, то вы сами за себя и не ожидайте, что кто-то будет напрягаться
И если Вы нажмёте на кнопочку «Показать ветку комментариев», то убедитесь, что я привожу эти примеры не потому, что утверждаю что они запустятся на Вашей системе, а в подтверждение моего утверждения в начале ветки:
run-скрипты daemontools/runit/s6 намного проще unit-файлов systemd.
у вас не выходит подтвердить это утверждение. получается только «нигде не работающие скрипты в простейшем случае ровно такой же сложности, как юнитфайл, но лишены всех его плюшек»
основная мысль состоит в том, что системд делает много нужного и решает существующие на практике проблемы, именно поэтому специально обученные люди, занимающиеся сервисами в мейнстрим дистрибутивах, перешли на него.
громкая критика системд слышна только от дилетантов, которые плохо разбираются и в сервисах в целом и в системд в частности.
кстати, раз уж он не в первый раз всплывает, рокет — сила, докер — могила.
и это, давно докер стал портабельным за пределы линуха(основной аргумент против сигрупп)? и про уязвимости
о бревне в глазу
список не полный, т.к. не включает всего, что запускается из баша и вообще игнорирует 800-фунтовую гориллу «написанный кривыми руками скрипт»
ExecStart= само по себе не использует $PATH, первое слово это полный путь к программе.
вы регулярно приводите примеры скриптов, которые не будут работать на моей системе (т.к. запускают бинари, которых у меня нет), несмотря на отсутствие башизмов.
почему перечисленный список сервисов чем-то важнее других(особенно, в контексте убивания сервиса)? откуда уверенность, что никто из этого списка не использует форк?
я уже несколько раз повторил: есть надежный способ убить все процесссы в сигруппе, нет надежного способа убить произвольное дерево процессов, которые в этот момент могут форкаться
правы только апологеты системд. можно взять кусок системд, он зависит не от системд, а от опубликованного интерфейса, реализовать интерфейс может кто угодно(другое дело, что чаще дальше криков дело не идет, но примеры альтернативных реализаций есть. упомянутый удевд используется всеми поголовно)
честно скажу, файл всегда удалить проще, чем строку.
вы не с той стороны заходите. я имел в виду, что по дефолту этой строки нет, а если хочется, то можно добавить строку. что проще, чем добавить файл(нет, это делает не админ в командной строке, а разработчик сервиса в редакторе)
делается одним простым файлом из, по сути одной строки (если не считать #!/bin/sh).
вам дали избыточный пример, который дает повод для критики непосвященным. в юнитфайле можно точно так же из одной строки(если не считать [Service]):
[Service]
ExecStart=/usr/bin/blalbla
я посчитал, это одинаковое количество символов с вашим скриптом. только тут на самом деле огромное количество фич включено по дефолту
как в этой ситуации помогает длинное описание?
понятнее вывод systemctl list-units? но, как мы уже выяснили, если вам не надо описание, вы его можете не писать. а если надо, то вам поможет только юнитфайл
И, Вы не поверите, но они там нафиг не нужны
не поверю, потому что я знаю, зачем они нужны. если, к примеру, у вас есть сервис, которому нужна база данных, то в системд он явно указывает зависимость. если вы не будете запускать сервис(а с сокет активейшн это превращается в «не будете пытаться коннектиться клиентом), то и базу данных никто запускать не будет(в отсутствие других клиентов базы данных). а как только понадобится запустить сервис, он стартанет и базу данных. все устаревшие альтернативы(включая апстарт с ивентами) вынуждены в такой ситуации просто сходу стартовать все, что в принципе установлено в систему, даже если оно может понадобиться только в следующее полнолуние, а может и не понадобиться вовсе
Вообще-то в s6 зависимость указывается именно одной строкой.
как это помогает раниту и демонтулс?
я не вижу реальной пользы от cgroups на практике для системных сервисов
хттпд — системный сервис? полезно ли на практике точно прибить его вместе со всеми форкающимися цги? „я не вижу пользы“ не всегда свидетельствует об отсутствии пользы, иногда это отсутствие знаний и вообще это странный аргумент против чего-то, в чем все остальные пользу видят
Иными словами, если пишется ./run-файл для runit, то в нём гарантированно можно использовать chpst для этих целей, а если он пишется для daemontools — то можно использовать вышеупомянутые утилиты.
а если пишется юнитфайл, то в нем гарантировано можно использовать синтаксис юнитфайлов. и это будет работать на любом мейнстрим дистре, в отличие от ранита и демонтулс
Что касается совместимости с POSIX sh, то она не требует ограничиваться в sh-скрипте исключительно командами включёнными в POSIX, иначе вообще практически ни один скрипт не может считаться совместимым.
почему? посикс описывает набор утилит. все остальное — это зависимость не на посикс, а на что-то другое.
Приватные маунты это прекрасно, но речь идёт о системных сервисах — кому из них нужны приватные маунты?
всем нужны, чтобы не видеть лишнего. но я строчку попросил не для системных сервисов(т.к. это умеет системд), мне и в простых скриптах надо
Разве в unit-файле ExecStart работает как-то иначе?
если «иначе» это «не зависит от /bin/sh», то да. чтобы запустить шелл из юнитфайла, надо запускать =/bin/sh ...., ну или =/bin/script.sh…
я не думаю, что кто-то использует csh вместо шелла, но есть много других вариантов с разной степенью корявости. если вы протестировали свой скрипт в системе х, где /bin/sh это bash, он совсем необязательно будет работать в системе у, где это ash
а покажите цепочку, которая настраивает несколько приватных маунтов, мне такое часто надо
ну и кстати, /bin/sh не делает ваш скрипт посикс совместимым, в моей посикс совместимой системе нет ни envuidgid, ни envdir. в этом и польза стандартизации системд
Это всё абсолютно портабельно
см выше. по сравнению с системд это все абсолютно непортабельно
А вот практически то же самое для daemontools/runit/s6, файл ./run в каталоге сервиса:
#!/bin/sh
exec /usr/bin/blalbla 2>&1
Отличие в том, что при остановке сервиса убивать его будут через SIGTERM, а не SIGINT
ну т.е. совсем не то же самое. чтобы убивать через сигтерм, в оригинальном примере достаточно удалить строку, он по дефолту так убьет. а не по дефолту (как в примере) делается одной простой строкой. но это не все отличия. в примере юнитфайла есть описание, в вашем примере никакого описания нет(нет, строка комментария не подойдет, описание из юнитфайла доступно программно для запущенных сервисов). в примере юнитфайла указано, куда этот сервис встраивается в дерево зависимостей, в вашем примере этого нет. и сделать это одной строкой нельзя. в примере юнитфайла автоматически работает огромное количество дефолтных плюшек, которых в вашем примере нет, потому что вы не слышали о пользе cgroups и т.д.
никогда не понимал зачем нужны cgroups для традиционных системных сервисов
это от нежелания ознакомиться с документацией по системд. они нужны например для того, чтобы можно было надежно остановить сервис, у которого форкаются процессы
Как и ожидалось, в статье нет ни слова про daemontools, runit или Supervisor, но вместо этого — ложная дихотомия sysvinit vs systemd
это легко объяснимо. раньше везде стоял сис5инит, теперь везде стоит системд, т.е. произошла массовая миграция с одного на другой. автор описывает этот процесс. с демонтулс на ранит никто не переходил и никакой трагедии не происходило, т.е. описывать нечего.
Поклонники systemd, однако, такие поклонники.
автор слегка разработчик фрибсд. видимо, его купили
а основным мотиватором системд-пид1 был лончд из макоси(тоже юникс, кстати) — на макось равняться православнее, чем на винды?
у вас не выходит подтвердить это утверждение. получается только «нигде не работающие скрипты в простейшем случае ровно такой же сложности, как юнитфайл, но лишены всех его плюшек»
громкая критика системд слышна только от дилетантов, которые плохо разбираются и в сервисах в целом и в системд в частности.
кстати, раз уж он не в первый раз всплывает, рокет — сила, докер — могила.
и это, давно докер стал портабельным за пределы линуха(основной аргумент против сигрупп)?
и про уязвимости
список не полный, т.к. не включает всего, что запускается из баша и вообще игнорирует 800-фунтовую гориллу «написанный кривыми руками скрипт»
вы регулярно приводите примеры скриптов, которые не будут работать на моей системе (т.к. запускают бинари, которых у меня нет), несмотря на отсутствие башизмов.
я уже несколько раз повторил: есть надежный способ убить все процесссы в сигруппе, нет надежного способа убить произвольное дерево процессов, которые в этот момент могут форкаться
можно начать с раздела The systemd for Administrators Blog Series
вам дали избыточный пример, который дает повод для критики непосвященным. в юнитфайле можно точно так же из одной строки(если не считать [Service]):
[Service]
ExecStart=/usr/bin/blalbla
я посчитал, это одинаковое количество символов с вашим скриптом. только тут на самом деле огромное количество фич включено по дефолту
понятнее вывод systemctl list-units? но, как мы уже выяснили, если вам не надо описание, вы его можете не писать. а если надо, то вам поможет только юнитфайл
не поверю, потому что я знаю, зачем они нужны. если, к примеру, у вас есть сервис, которому нужна база данных, то в системд он явно указывает зависимость. если вы не будете запускать сервис(а с сокет активейшн это превращается в «не будете пытаться коннектиться клиентом), то и базу данных никто запускать не будет(в отсутствие других клиентов базы данных). а как только понадобится запустить сервис, он стартанет и базу данных. все устаревшие альтернативы(включая апстарт с ивентами) вынуждены в такой ситуации просто сходу стартовать все, что в принципе установлено в систему, даже если оно может понадобиться только в следующее полнолуние, а может и не понадобиться вовсе
как это помогает раниту и демонтулс?
хттпд — системный сервис? полезно ли на практике точно прибить его вместе со всеми форкающимися цги? „я не вижу пользы“ не всегда свидетельствует об отсутствии пользы, иногда это отсутствие знаний и вообще это странный аргумент против чего-то, в чем все остальные пользу видят
почему? посикс описывает набор утилит. все остальное — это зависимость не на посикс, а на что-то другое.
всем нужны, чтобы не видеть лишнего. но я строчку попросил не для системных сервисов(т.к. это умеет системд), мне и в простых скриптах надо
я не думаю, что кто-то использует csh вместо шелла, но есть много других вариантов с разной степенью корявости. если вы протестировали свой скрипт в системе х, где /bin/sh это bash, он совсем необязательно будет работать в системе у, где это ash
а покажите цепочку, которая настраивает несколько приватных маунтов, мне такое часто надо
ну и кстати, /bin/sh не делает ваш скрипт посикс совместимым, в моей посикс совместимой системе нет ни envuidgid, ни envdir. в этом и польза стандартизации системд
см выше. по сравнению с системд это все абсолютно непортабельно
автор слегка разработчик фрибсд. видимо, его купили
у меня для вас есть новость. спо ортогонально коммерческости. редхат весь из себя коммерческий и на 100% спо