Dotaz: Problém s init skriptem pod systemd (předání argumentů)

[MilanC]

Ahoj, kdysi jsem si napsal init.d skripty na spouštění a manipulaci s více instancemi dvblast+ffmpegu. Provozoval jsem jej do teď na Ubuntu 16.04, kde jsem toho času i z jiných důvodů vyhodil systemd a místo něj dal upstart-sysv a sysvinit. Nyní ten systém migruji na Ubuntu 20.04 a narazil jsem na problém. Můj init skript totiž používá další argument, kterým je konfigurační soubor. Tedy můžu z řádku ručně volat něco jako /etc/init.d/mujskript restart config1

Usage: $0 {start|stop|restart|force-reload} [config_file]

Funguje to tak, že pokud se volitelný parametr config neurčí, operace se provede nad všemi configy = instancemi. Pokud se určí, provede se operace jen nad danou instancí (třeba restart). Nyní jsem v systemd narazil, protože tam se předává jen první parametr (stop/start/restart/atd.), ale druhý už ne. Mám další aplikaci, která toto volání init skriptu využívá v případě potřeby manipulace s danou instancí, to ale můžu případně upravit, jak bude potřeba. V podstatě vše se řídí a určuje počtem konfiguračních souborů v daném umístění. Pro představu, ten jednodušší skript pro bvblast vypadá takto: https://pastebin.com/wYURJBMN

Hledám možné řešení...

1. Je možné v Ubuntu 20.04 zase vyhodit systemd? (návody, co jsem dohledal jsou na nižší verze, tak nevím, https://appuals.com/remove-systemd-ubuntu-permanently/). Nezadělám si na nějaké problémy? Nevím, jak je to v této verzi moc navázané. Bylo by to nejjednodušší řešení bez dalších nutných úprav.
2. Mohu to přepsat a na každou instanci/config mít extra init skript odkazující na konkrétní config, ale trochu to znepříjemní správu, protože počet instancí se na různých strojích liší a mění i v čase. Prostě do teď to fungovalo zcela bezúdržbově.
3. Nějak donutit systemd, aby mi tam pouštěl i ten druhý argument?
4. Mít jeden init skript a na něj udělat různé služby v systemd per config? Se systemd příliš neumím, tak se toho trochu bojím. A opět přemýšlím, jestli by se to dalo nějak automatizovat.
5. Nějaké jiné doporučené řešení?

Děkuji.

---

---

Odpovědi

[Max]

3) systemd - Giving my service multiple arguments
Zdar Max

[MilanC]

Ahoj, tohle jsem našel, ale vůbec se mi to nelíbí. Ale je možné, že jsem to nepochopil. Jde ideálně o tu bezúdržbovost, což do teď fungovalo. Prostě jsme jen nakopírovali konfigy do adresáře, tam je upravili a nic víc se neřešilo. Pokud možno bych se chtěl vyhnout ruční editaci těch systemd služeb.

Leda by to šlo nějak automatizovat, třeba mít nějaký skript, který by iteroval ty konfigurace v adresáři a pro každou založil tu službu v systemd? A tento skript bych pouštěl někde úplně na začátku, aby případně došlo k aktualizaci, pokud by někdo nějaký config umázl/přidal. Šlo by to takto nějak?

[...]

Ubuntu nevím, ale ono se to od debianu nebude moc lišit. Takže v debianu, když si nainstaluješ třeba OpenVPN, tak se to dá pouštět dvěma způsoby. Představ si, že máš v několik konfiguračních souborů v jednom adresáři. Takže pomocí openvpn.service spustíš všechny ty konfigurace najednou. Ale když bys chtěl spouštět ty konfigurace nezávisle ne sobě, můžeš to spouštět jako openvpn@prvni_konfig.service, openvpn@druhy_konfig.service. Pomoci nějaké volby systemd, kterou si nepamatuji, si to z toho názvu service načte to "druhy_konfig" a podle toho použije jiný konfigurační soubor. Tímhle způsobem by se patrně daly spouštět i ty tvoje služby.

[Peter Golis]

Ževraj to funguje. Bol to tretí link pri vyhľadaní systemd service parameters, vyberal som podľa názvu.

[Andrej]

Nauč se se Systemd. Ušetří ti to mnoho starostí (a přidá jen pár).

Namísto initscriptu napíšeš unit, kde uvedeš příkaz pro spuštění dané služby. Ten příkaz uvedeš pro spuštění na popředí s klasickým stdout/stderr výstupem. Systemd to spustí na pozadí, uloží log, při pádu restartuje,… ušetří to mnoho starostí.

Pro tvůj příklad by dvblast.service vypadalo nějak takto:

[Unit]
Description="Muj krasny dvbast %i"
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/dvblast
EnvironmentFile=/etc/default/dvblast
User=dvblast
Group=dvblast
Environment="ADAPTER=%i"

[Install]
WantedBy=multi-user.target

To %i je název instance, takže když nastartuješ dvblast@adapter1.service, tak proměnná ADAPTER bude "adapter1". Viz https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Specifiers.

Plus/mínus nějaké detaily by to mělo kompletně nahradit ten tvůj initscript. PID file nemusíš řešit, to pořeší systemd pomocí cgroups. Logování také dostaneš zdarma.

[GeorgeWH]

A bude mu to fungovat automaticky? To znamena, ze ked niekde prida nejaky konfig, tak nemusi nic ine urobit a moze danu instanciu ovladat a pri bootovani to startne?

[Josef Kufner]

Myslím, že stačí konkrétní instanci povolit, tím se vyrobí symlink a systemd tak ví, že existuje.

[Pavel 'TIGER' Růžička]

Máš de facto dvě možnosti. Buď používat no systemd distribuci a nebo se naučit systemd. Já jsem na tom tak, že systemd sice sleduji, ale zatím jej pořád nepoužívám. Místo toho jedu devuan, či artix. Tuším, že i MX je bez systemd. U toho si však nejsem jist, neb jej nepoužívám

[MilanC]

Jen doplním k navrhovanému bodu 1. Toto už není v ubuntu 20.04 možné, protože v repo chybí dané balíčky pro upstart. Předpokládám tedy, že v této verzi už systemd nahradit nejde, proto také na to nelze dohledat návod jako u předchozích verzí Ubuntu.

Jdu tedy více studovat systemd.

[MilanC]

Ahoj,

postupně se tím prokousávám, něco jsem si načetl, ale mám pár dalšíchdotazů. Vytvořil jsem si hlavní service a pak další pro jednotlivé configy... https://pastebin.com/GvifjVwp, zatím to tedy nic moc nedělá, spíše s tím pokusuji.

# systemctl list-units --all | grep ffmpeg-hls-restream
  ffmpeg-hls-restream.service                                                              loaded    inactive dead      FFmpeg restream to HLS
  ffmpeg-hls-restream@stream101.service                                                    loaded    inactive dead      FFmpeg restream to HLS for stream101
  ffmpeg-hls-restream@stream102.service                                                    loaded    inactive dead      FFmpeg restream to HLS for stream102
  ffmpeg-hls-restream@stream103.service                                                    loaded    inactive dead      FFmpeg restream to HLS for stream103
  ffmpeg-hls-restream@stream104.service                                                    loaded    inactive dead      FFmpeg restream to HLS for stream104

Chtěl bych se zeptat jestli je dan0, že se hlavní service spustí vždy před těmi dalšími konfiguračními? Lze to případně zajistit? Abych automatizoval zakládání a odmazávání neplatných services per config, chtěl bych před těmi dílčími vykonat skript, který by vypadal nějak takto:

CONFIGDIR="/etc/ffmpeg-hls-restream"

systemctl stop ffmpeg-hls-restream@*
systemctl disable ffmpeg-hls-restream@*
systemctl daemon-reload
systemctl reset-failed

for CONFIGFILE in $CONFIGDIR/*.conf; do
    CONFIGFILE=$(basename -- "$CONFIGFILE")
    CONFIG="${CONFIGFILE%.*}"
    systemctl enable ffmpeg-hls-restream\@${CONFIG}
done

Prostě před vlastním spouštěním úloh pro jednotlivé konfigurace tento seznam nejprve aktualizovat. Až pak startovat. Oba soubory jsem zkopíroval do /etc/systemd/system/, v /etc/systemd/user/ mi je to nějak nevidí.

Díky.