rulinux.net - Форум - Talks - systemd.. пара слов..

Re:systemd.. пара слов..

Wed, 05 Apr 2017 12:03:27 +0300

> Настоящие выдумщики-то..

Fabrice Bellard.. qemu, ffmpeg, tinygl..

Re:systemd.. пара слов..

Wed, 05 Apr 2017 11:08:14 +0300

Настоящие выдумщики-то вот:

TCCBOOT is a boot loader able to compile and boot a Linux kernel directly from its source code.

TCCBOOT is only 138 KB big (uncompressed code) and it can compile and run a typical Linux kernel in less than 15 seconds on a 2.4 GHz Pentium 4.

TCCBOOT is based on the TinyCC compiler, assembler and linker. TinyCC is an experiment to produce a very small and simple C compiler compatible with the GNU C compiler and binary utilities.

Re:systemd.. пара слов..

Wed, 05 Apr 2017 10:42:22 +0300

> С недавних пор более-менее навороченные^1 "скрипты" пишу на Си и запускаю через #!/usr/bin/tcc -run, чего и вам желаю

экий Вы, батенька, выдумщик.. а как же православный csh ?! :)

> Ну так и научи его уму-разуму:

"научить" - не проблема. после чего придётся лочить текущую версию systemd. только из-за нежелания так поступать колхозил "лекарство". и вроде оно таки заработало.. смотрю на Slackware - пичалько.. объём возни с "допилом" (под наши требования/потребности) - over 9000.. вот и крутись как хош..

> жутко монструозными или требуют какой-никакой математики

по какой-то неведомой причине всегда вспоминаю sedtris:
git clone https://github.com/uuner/sedtris.git

> /usr/bin/hostname.exe

истину глаголешь..

Re:systemd.. пара слов..

Wed, 05 Apr 2017 09:15:23 +0300

> на баше тяжело писать нормально в принципе
А при чём тут инит (PID 1)? Можно же писать загрузочные скрипты и на csh. Можно и на много чём ещё и даже тупо бинарники накомпилять под конкретную систему/конфигурацию. Разве нет?

> ибо всё же bash позволяет вносить изменения в код без последующего компилирования исходника.
С недавних пор более-менее навороченные¹ "скрипты" пишу на Си и запускаю через #!/usr/bin/tcc -run, чего и вам желаю.

> выяснил, что "виноват" /usr/bin/hostname
Ну так и научи его уму-разуму:

bash

mv /usr/bin/hostname{,.exe}

cat > /usr/bin/hostname << EOF

#!/bin/sh

/usr/bin/hostname.exe --file /etc/hostname

EOF

chmod +x /usr/bin/hostname

---

¹ те, которые на баше получаются жутко монструозными или требуют какой-никакой математики

Re:systemd.. пара слов..

Tue, 04 Apr 2017 17:54:47 +0300

> Я тут, если что, не системд защищаю, а скорее sysv критикую.

дык, понятное дело.. жытейское..

> Как будто в sysv иначе.

да. иначе. внезапно..

> 1) на баше тяжело писать нормально в принципе

вот мы и подошли к сути: "Advanced Bash" - ни разу не подарок, хотя позволяет оч многое. субъективно ессно, когда стал подходить к скриптам аналогично C/Pascal, т.е. логика - отдельно, функции - отдельно и все переменные объявляем в "заголовке" заранее, - мне понра. "Следовательно, разруха не в клозетах, а в головах."(ц)(проф. Преображенский)

> 2) конкретному пользователю ничуть не легче от этого.

не согласен, ибо всё же bash позволяет вносить изменения в код без последующего компилирования исходника. хотя эт как плюс, так и минус. в какой-то мере и степени..

>> убивает что полезли всякиее реестроподобные штуки и проч.

> На что только не пойдут поттеринги лишь бы не хранить настройки в Постгрессе

Господа.. не знаю как Вам, а мне видится главным отличием меж Windows и Linux/Unix лишь то, что последний работает именно так, как "написано" (info, man, source, posix, rfc.. до недавнего времени те же конфиги в /etc/..). на примере же systemd наблюдаю забивание болта на стандарты и (намеренное) усложнение системы с последующими ошибками в работе компонентов. на моих глазах система теряет управляемость, "читаемость", логику, простоту.. теряет свои сильные стороны.. лан.. об этом - позже и в другом трэде..

сегодня ещё раз смотрел на безобразие с именами хостов.. чуток поправил самописный "юнит"

> cat /etc/systemd/system/set_hostname.service

bash

[Unit]

Description=Set hostname for..

After=getty@.service getty@tty1.service getty@tty2.service getty@tty3.service getty@tty4.service getty@tty5.service getty@tty6.service

After=kbd.service

After=firewall.service

After=dbus-org.freedesktop.hostname1.service

After=systemd-hostnamed.service

After=systemd-firstboot.service

[Service]

# ExecStartPre=/usr/bin/touch /var/lock/subsys/local

ExecStartPre=/usr/bin/hostname --file /etc/hostname

ExecStart=/usr/bin/hostnamectl set-hostname Требуемое_Имя_Хоста

[Install]

WantedBy=multi-user.target

WantedBy=default.target

WantedBy=graphical.target

WantedBy=runlevel3.target

WantedBy=runlevel5.target

WantedBy=network.target

WantedBy=getty.target

конструкция избыточна. более того, засадил в cron её повторный запуск раз в 2 часа (в лучших традициях Windows, если кто писал сервисы под неё :) и непосредственно каждый раз перед запуском иксов). выяснил, что "виноват" /usr/bin/hostname, который тащит непойми откуда совершенно ненужное и не смотрит на значение в /etc/hostname, хотя просто обязан это делать в первую очередь.. пробую теперь заставить этот юнит срабатывать непосредственно перед авторизацией юзера в системе. при повторном логине уже норм, а вот при первоначальном логине в консоль, хоть и добился должного состояние всех переменных (env/set), но $PS1 (\h\) мя пока не радует..

Re:systemd.. пара слов..

Tue, 04 Apr 2017 16:41:32 +0300

На что только не пойдут поттеринги лишь бы не хранить настройки в Постгрессе.

Re:systemd.. пара слов..

Tue, 04 Apr 2017 14:57:46 +0300

убивает что полезли всякиее реестроподобные штуки и проч.

Re:systemd.. пара слов..

Tue, 04 Apr 2017 10:49:36 +0300

>скрипт инита был в едином файле (sysvinit) и/или те же условия rc.conf из BSD
Скрипт инита-то был в едином файле, но инит-скрипты на баше могли простираться на десяток. Достаточно, например, посмотреть на инит-скрипт какого-нибудь rabbitmq в дебиане и п. Он, к слову, ещё и работает через раз. но это нюансы, спасибо start-stop-daemon.

Никто, естественно, не мешает придумать такую же конструкцию на системд, или апстарте, или ещё чём-либо, но проблема sysv в том, что там часто иначе никак. Либо простыня на 300 строк с грепами, авками и старт-стоп-демонами (да, меня он триггерит), либо ничего. Не предоставляет инит никаких нормальных инструментов для работы с приложениями, а должен, потому что это его задача, и часто никто, кроме процесса с pid 1, не может быть альтернативой (например, никто кроме инита не может отслеживать убежавшие от родителей процессы).

Типичный ответ сторонника старого и проверенного обычно выглядит как "переписывай свою программу, чтобы всё сама могла и не падала". Спасибо, особенно когда программа не моя.

>необходимость рыть исходники этого поделия бесит..
>не было нужды проверять все активные target-ы, шарить в поисках ExecStop и/или драного EnvFile=..
Как будто в sysv иначе. У меня, например, на то же дебиане, помнится, не работали uwsgi и rabbitmq. Пришлось сначала долго бегать по баш-файлам, которые включают в себя ещё баш-файлы, а потом ставить в них echo и рассматривать, где же проблема, рассматривать их env и т.д.. А проблема на самом деле в том, что без километровой простыни ничего хорошего с sysv сделать не получается. Итого сидим и по полчаса медитируем над скриптами.

Тут можно обвинять конкретных скриптописателей, но 1) на баше тяжело писать нормально в принципе, он негибкий и совершенно невыразительный 2) конкретному пользователю ничуть не легче от этого.

Я тут, если что, не системд защищаю, а скорее sysv критикую.

Re:systemd.. пара слов..

Tue, 04 Apr 2017 08:24:20 +0300

> Осталось HTML-темплейты и лайки туда присобачить.
Веб-сервер же присобачили. Дело за малым - найти умельца, который присобачит твиттер и смайлики.

Re:systemd.. пара слов..

Mon, 03 Apr 2017 19:04:41 +0300

>> А в чём, кстати, выражается решение с адресом? Не сам же DHCP сервер будет имена хостов резолвить?
DHCP сервер может присобачить имя домена пулу адресов и вернуть клиенту. да, DNS (тот же bind) и DHCP - это разные сущности, но возможность возврата (доменного) имени клиенту у DHCP есть. в целом же задача DHCP сервера принять запрос и выбросить ответ с одним из адресов из доступного пула. в RFC2132 есть вагон опций: маршрутизация и т.п.. много всего. также DHCP сервер может выбросить Ip по "идентификатору"/имени клиента/хоста, причём может вернуть Ip со сменой этого "идентификатора". в данном случае, как и говорил ранее, хост/клиент обязан принять IP, но смену "имени" может проигнорировать.

это мы ещё не лезем в PXE, tftp, тэгирование и прочие няшные вещи ..

Re:systemd.. пара слов..

Mon, 03 Apr 2017 18:36:00 +0300

А в чём, кстати, выражается решение с адресом? Не сам же DHCP сервер будет имена хостов резолвить?

Re:systemd.. пара слов..

Mon, 03 Apr 2017 17:49:31 +0300

> DHCP получает от хоста DHCP_CLIENT_ID и/или DHCP_HOSTNAME
нет. чуток не так. мы имеем: MAC Address > Ip > Name > прочее.. т.е. у нас абстракции - всё, кроме "MAC Address" интерфейса. поэтому arp и lease собсно идут именно на MAC. любой DHCP сервер на основании MAC может решить с адресом и/или именем клиента. но! соответствие имени клиента (доменного в частности) на интерфейсе с записями FQDN/MX/A/прочими - это сугубо на совести клиента.

как-то так.

Re:systemd.. пара слов..

Mon, 03 Apr 2017 17:37:44 +0300

Варианты, как я понимаю, DHCP получает от хоста DHCP_CLIENT_ID и/или DHCP_HOSTNAME и прописывает его как попрошено, либо назначает то, что сконфигурено в роутере для заданного MAC-адреса. Вопрос только в том, что более приоритетно.

Re:systemd.. пара слов..

Mon, 03 Apr 2017 17:31:31 +0300

пмсм есть RFC2131 - Dynamic Host Configuration Protocol, RFC2132 - DHCP Options and BOOTP Vendor Extensions и RFC4702 с ещё более длинным именем.. в частности пункт 3.5 rfc4702:
https://tools.ietf.org/html/rfc4702

в сухом остатке: выбор имени хоста - сугубо приоритет клиента. клиент может как использовать выделенное (доменное) имя, так и спокойно вешать своё на интерфейс.

Re:systemd.. пара слов..

Mon, 03 Apr 2017 17:20:08 +0300

Кстати, а для тех, кто не спец, это вообще нормально получать хостнейм по сети? У меня ситуация в точности наоборот -- хостнейм прописан в /etc/rc.conf, а по сети dhcp сервер дает айпишник и обновляет dns зону в соответствии с айпишником и данным ему хостнеймом.

Re:systemd.. пара слов..

Mon, 03 Apr 2017 17:19:31 +0300

>> Вау.. Осталось HTML-темплейты и лайки туда присобачить.
именно.. лунный модуль с блэкджэком и шлюхами.. "уплочено"(ц)(тм)..

Re:systemd.. пара слов..

Mon, 03 Apr 2017 17:15:52 +0300

> set-icon-name

Вау.. Осталось HTML-темплейты и лайки туда присобачить.

Re:systemd.. пара слов..

Mon, 03 Apr 2017 17:09:02 +0300

>> это отдельный бинарник, который не что иное, как УНИХ-вей

если кто-то считает, что machinectl и hostnamectl являются критически необходимыми компонентами системы.. их аффтар, например.. то даже не знаю, что и сказать..

что думать, когда сейчас имею ситуёвину (man hostnamectl):

bash

NAME   

       hostnamectl - Control the system hostname

SYNOPSIS

       hostnamectl [OPTIONS...] {COMMAND}

DESCRIPTION

       hostnamectl may be used to query and change the system hostname and related settings.

       This tool distinguishes three different hostnames: the high-level "pretty" hostname which might include all kinds of special characters (e.g. "Lennart's Laptop"), the static hostname which is used to initialize the kernel hostname at boot (e.g. "lennarts-laptop"), and the transient hostname which is a default received from network configuration. If a static hostname is set, and is valid (something other than localhost), then the transient hostname is not used.

имя хоста ("static hostname" по версии systemd) прописано не только в указанном в мане "/etc/hostname", но и в "/etc/hosts". тем не менее несколько раз за сессию юзера именно systemd перетирает его на "transient". ???!

вот это ублюдство: "three different hostnames" - это вообще откуда и зачем?! RFC? нет, никак не связано с RFC. может привязано к /etc/hosts? - тоже нет. далее в том же "мануале" видим дивные директивы: set-icon-name, set-chassis, set-deployment, set-location.. и это всё в PID №1..

machinectl - эт то же самое, только в профиль.

для справки: systemd 228. версии 218 и ранее ведут себя корректно (hostnamectl), что характерно..

Re:systemd.. пара слов..

Mon, 03 Apr 2017 16:54:31 +0300

>> unix-way: делать простые вещи, но делать их хорошо

> Адепты systemd на это возражают так:
> это отдельный бинарник, который не что иное, как УНИХ-вей.

Мде.. У systemd даже адепты какие-то неадекватные!

Re:systemd.. пара слов..

Mon, 03 Apr 2017 15:51:45 +0300

> systemd - это НЕ unix-way
Адепты systemd на это возражают так: каждый элемент systemd (machinectl, hostnamectl, ...) - это отдельный бинарник, который не что иное, как УНИХ-вей.

Re:systemd.. пара слов..

Mon, 03 Apr 2017 15:45:51 +0300

>> Проблема не в том, что в systemd надо как-то по-другому писать сценарии, а в том, что systemd всасывает в себя сторонние базовые проекты, такие как udev, syslog, ...

ещё одна мысль, которую не доводят до логического завершения.. unix-way: делать простые вещи, но делать их хорошо. точка. абзац. systemd - это НЕ unix-way. вот в чём суть.. кому в posix системе нужен systemd - думаю понятно (Шляпа + Энтерпрайз = Бабло ...)

как итог - система становится неуправляемой. как Windows. именно так. вернее ты, как админ, для исправления чего-либо связанного с systemd, уже обязан рыть исходник и махать компилятором..

и всё это идёт постепенно по нарастающей. уровень "энтропии" увеличивается, ломается то, что работало и появляются все эти machinectl, hostnamectl ..

Re:systemd.. пара слов..

Mon, 03 Apr 2017 12:58:25 +0300

Проблема не в том, что в systemd надо как-то по-другому писать сценарии, а в том, что systemd всасывает в себя сторонние базовые проекты, такие как udev, syslog, ...

Re:systemd.. пара слов..

Mon, 03 Apr 2017 12:02:07 +0300

>> machinectl - где-то то же самое, что и описанный выше hostnamectl

> Вообще это такой инструмент для управления контейнерами и их образами в стиле docker/lxd. Обычно его вообще трогать не надо, если ты этим не пользуешься.

давайте же закончим мысль: что machinectl, что hostnamectl - "ненужно"(ц)(тм), не? очередной пример того, как рушат логично работающую систему/компонент. чесслово, до сих пор не понимаю когда именно (т.е. не вижу чётких условий выполнения) происходит подмена имени хоста на значения "transient". и самое весёлое, что эта дрянь срабатывает не единожды за сессию юзера..

>> переписываем скрипты включения, выключения, стэндбай, гибернации и т.п. на "systemctl"

> Зачем? Всевозможные suspend, poweroff и прочие должны оставаться рабочими.

угу, "рабочие".. симлинки из /sbin/${subj} на "systemctl". на всех ноутах пришлось ковырять "бивис" и скриптами писать режимы энергосбережения, гибернации и т.п.. хотя вполне возможно, что частный случай.. (MSI)

>> Хотя, судя по тексту, что-то в дистрибутиве явно не так. Например, нерабочая vconsole это довольно странно.

не видел работающих примеров systemd без иксов с корректной локалью без ручного вмешательства. ни одного.

>> вменяемых

>> прозрачных

> Ах, если бы...

?! скрипт инита был в едином файле (sysvinit) и/или те же условия rc.conf из BSD. не было нужды проверять все активные target-ы, шарить в поисках ExecStop и/или драного EnvFile=.. более того, самое смешное начинается, когда аргументом у ExecStart=${shell_script_file} .. а "информативность и актуальность"(ц)(тм) текущих error-messages у systemd никого не напрягает?

необходимость рыть исходники этого поделия бесит..

Re:systemd.. пара слов..

Sun, 02 Apr 2017 18:26:02 +0300

>machinectl - где-то то же самое, что и описанный выше hostnamectl
Вообще это такой инструмент для управления контейнерами и их образами в стиле docker/lxd. Обычно его вообще трогать не надо, если ты этим не пользуешься.

>переписываем скрипты включения, выключения, стэндбай, гибернации и т.п. на "systemctl"
Зачем? Всевозможные suspend, poweroff и прочие должны оставаться рабочими.

Хотя, судя по тексту, что-то в дистрибутиве явно не так. Например, нерабочая vconsole это довольно странно.

>вместо вменяемых и прозрачных скриптов
>вменяемых
>прозрачных
Ах, если бы...

Re:systemd.. пара слов..

Sun, 02 Apr 2017 13:43:06 +0300

че приебался

Re:systemd.. пара слов..

Sun, 02 Apr 2017 07:21:49 +0300

Ранлевелы, хуеволы.

Вот в BSD самые удобные скрипты, имхо. Зависимости есть? Есть. Можно отключить сервис в rc.conf, можно передать дополнительные параметры. Всяческие дополнительные переменные для упрощения. Например, нужно тупо выполнить какую-то комманду или подгрузить модуль -- есть переменные для этого. А как сейчас в линуксе я даже и не знаю

Re:systemd.. пара слов..

Sat, 01 Apr 2017 19:33:55 +0300

\i>> {поддержать функционал}
\i> {Вы делаете мне больно.}

извините.. имел в виду лишь то, что systemd по сути поставил процесс инита с ног на голову. если сравнивать с sysvinit и/или "rc/bsd init". субъективно.

грубо говоря, мне трудно на данный момент провести разграничение меж systemd и, скажем, инитом crux/bsd, где тупо всё запихано в один файл с форками в бэкграунд всего и вся.. и то и то сукесфули взлетит, что характерно, при отсутствии элементарных ошибок в синтаксисе комманд и при соблюдении элементарной логики..

потеря же функционала sysvinit-а печалит.. "chkconfig" был прекрасен.. помянем.. типичный sysvinit сервис был прозрачен, описывал все свои стадии (case ... esac) и был жёстко вписан в структуру runlevel-а. by default.. by design..

unit и target в systemd как-бы "размазали" целостность инит-сервиса.. только кому от этого стало легче/лутьчьше? "читать" и понимать систему стало тяжелее, как мне кажется.

>> А вообще по сабжу, как давно уже этот systemd внедрили, а до сих пор жалуются. Неужели в ляликсе настолько всё плохо?

вне консоли этот ~~няш~~ваш Linux сосёт. десктопный Linux - есть суть феерический пиздецЪ. сидя в bash/ssh + screen + urxvtd + mutt + vim + w3m + {curses/ncurses} ситуацию вижу именно так. как-нить соберусь с духом и оформлю тут трэд на эту тему.. печально всё.. увы..

Re:systemd.. пара слов..

Sat, 01 Apr 2017 18:31:03 +0300

> поддержать функционал
Вы делаете мне больно.

А вообще по сабжу, как давно уже этот systemd внедрили, а до сих пор жалуются. Неужели в ляликсе настолько всё плохо?

Re:systemd.. пара слов..

Sat, 01 Apr 2017 17:30:22 +0300

ХЗ, так сильно не углублялся, но стартовые скрипты сервисов стало писать сложнее, особенно по сравнению с upstart.

Re:systemd.. пара слов..

Sat, 01 Apr 2017 15:19:08 +0300

Лол, ещё один прозрел.

systemd.. пара слов..

Sat, 01 Apr 2017 14:33:31 +0300

фсем - Бобра, дорогие Товарищи..

если не в лом - добавьте, отпинайте и т.д. и т.п.. ниже - сугубо частный опыт "общения" с сабжем. пара ссылок на спецолимпиаду по "systemd":
оно сосёт..(eng)
аргументы против systemd (eng)
Торвальдс и Т'со о сабже (eng)
и т.д. и т.п..

субъективно: когда прозрачная работающая (твоими заботами) система меняет несколько ключевых компонентов (картинко в третьей ссылке выше) на нечто новое, что, в добавок ко всему, неспособно сразу "из коробки" поддержать функционал на прежнем уровне (опять же, без твоего ручного вмешательства) - эт не может не радовать. однозначно. чсбх.. ощутимо прибавилось работы по контролю unit/target/service файлов, потеря чёткой/привычной структуры runlevel-ов тому причина.

"История Успеха"(ц)(тм) в хронологическом порядке:
\list {
{*} слетел автологин (/etc/inittab более не актуален). прописываем отдельно в "getty@tty${number}.service". опционально выключаем мусор логов в tty: dmesg -D.
{*} до сих пор не работает настройка клавиатуры/локали (vconsole, фреймбуфер, без иксов). восстанавливаем старый добрый kbd.service (кому он мешал?!)

bash

> cat /etc/systemd/system/kbd.service 

[Unit]

Description=Keyboard KBD Service

After=getty@tty1.service getty@tty2.service getty@tty3.service getty@tty4.service getty@tty5.service getty@tty6.service

[Service]

EnvironmentFile=-/etc/sysconfig/console

ExecStartPre=-/usr/bin/setfont $CONSOLE_FONT

EnvironmentFile=-/etc/sysconfig/keyboard

ExecStart=/usr/bin/loadkeys $KEYTABLE

[Install]

WantedBy=multi-user.target

{*} перетряхиваем правила udev/dbus, ибо ..
{*} переписываем скрипты включения, выключения, стэндбай, гибернации и т.п. на "systemctl"
{*} (!sic.!) охуеваем от hostnamectl и пытаемся как-то вернуть актуальность записям в /etc/hosts, /etc/hostname .. цимес в том, что systemd считает имя хоста, получаемое по dhcp, например, более "приоритетным", чем запись/записи в /etc/hosts и /etc/hostname. переменные $HOSTNAME и $HOST перетирает при первом же удобном случае значением "transient". не лениццо, сцуко, этот "транс" запихать в .Xauthority/$XAUTHLOCALHOSTNAME/.serverauth.${number} .. последующий пиздец немного предсказуем.. перчика добавляет нежелание/неумение systemd работать с глобальными переменными, что опять же характерно. оно ж PID №1 и вертело всех на хую боком.. костылём является директива "EnvironmentFile=". варианты пляски с бубном:
\num {
{*} добавляем HOSTNAME="Наше_Имя" и DHCP_HOSTNAME="Наше_Имя" в /etc/sysconfig/network/ifcfg-${iface}
{*} рисуем ещё один "юнит".. как это мило..

> cat /etc/systemd/system/set_hostname.service

[Unit]
Description=Set hostname for..
After=getty@.service getty@tty1.service getty@tty2.service getty@tty3.service getty@tty4.service getty@tty5.service getty@tty6.service
After=kbd.service
After=firewall.service

[Service]
# ExecStartPre=/usr/bin/touch /var/lock/subsys/local # опционально
ExecStart=/usr/bin/hostnamectl set-hostname --transient --no-ask-password Наше_Имя_Буквами

[Install]
WantedBy=multi-user.target
WantedBy=default.target

если иксы стартуют сервисом - обязательно перед этим делаем [ре]старт сего "юнита".
}
{*} machinectl - где-то то же самое, что и описанный выше hostnamectl.. встречайте /etc/machine-id ..
{*} бинарные логи ( >last -f ${filename}) бесполезны чуть менее, чем полностью. помним о rsyslog/syslog/ulogd/etc, не забываем контролировать/чистить бинарный мусор в /var/ ..
{*} "systemd-analyze blame" без "dmesg | less" - говно. утверждения о преимуществах в скорости запуска systemd vs sysvinit крайне субъективны и, скорее всего, некорректны. поддержка средствами systemd функционала runlevel-ов возможна, но требует в разы более времени на организацию, ибо target должен не только запускать, но и останавливать/перезапускать сервисы/юниты..
}

как мне кажется, вместо вменяемых и прозрачных скриптов sysvinit-а мы в лице systemd получили некую приблуду, требующую в разы больших усилий для организации и поддержки функционала. кроме того, systemd уже требует от админа знания C и умения/желания читать/править исходники.. advanced bash конечно тоже не подарок, но таки компилятора не требует, ога..

спасибо за внимание.