systemd ?

S niektorými bodmi súhlasím a sám na desktope len tak mimochodom systemd nepoužívam. Vlastne nemám rád žiaden softvér od Lenarta Poetteringa, vyslovene neznášam povýšenecké správanie z jeho strany, zľahčovanie hlavne bezpečnostných chýb, návrh typu monolit atď.

Ale

Teraz opíšem situáciu, ktorú som naposledy riešil so systemd a zároveň s init skriptmi.

Potreboval som narýchlo urobiť ssh tunel, ktorý by bežal spoľahlivo po naštartovaní siete. Išlo zhruba o tento príkaz:

ssh -N -R port:host:port \
    -o ServerAliveInterval=60 \
    -o ExitOnForwardFailure=yes \
    user

Ok, človek si povie, jednoduchá záležitosť. Takže si pozrie manuál k svojej distribúcii, nejakú tú kostru init skriptu. Takže človek si skopíruje asi 150-riadkový skript, aby spustil jeden príkaz. Ok, dá sa to napísať aj od nuly, uznávam.

Takže po zbežnom preštudovaní, ako sa to spúšťa v danej distribúcii (väčšinou start-stop-daemon, ale neplatí univerzálne) mám funkčný skript. A funguje. Pol hodiny. Nuž zabudol som upozorniť, že moje pripojenie je ehm občas divoké.

Namiesto funkčnej služby je teraz služba vo vypnutom stave. Teda ak neexistuje proces s daným pid-om. V linuxe sú pidy znovu používané, takže medzitým číso procesu môže mať úplne iný proces a pre skript sa bude tváriť ako naštartovaná služba. Čo je horšie, že keď teraz reštartujem službu môžem si zostreliť náhodný proces.

Ok, teraz trochu preháňam. V skutočnosti v niektorých distribúciách niektoré init skripty niekedy kontrolujú aj názov procesu. No niekedy.

Takže hackujem ďalej. Potrebujem ssh obaliť do nejakého iného skript, alebo inej binárky, ktorá bude v prípade havárie znovu štartovať ssh. Ak to bude skript - nebude fungovať zostrelenie podľa názvu, ale len podľa pidu. Okrem toho musí sa implementovať obsluha signálov, menovite tuším SIGTERM / SIGHUP, aby skript zostrelil následne svoje deti.

Ako sa to rieši pod systemd?

Napíšem 5-riadkovy unit. Systemd sa postará o štart so správnymi závislosťami (sieť), reštartuje ak sa reštartuje sieť, znovu naštartuje ak bol proces ukončený, konfigurácia je v externom súbore, takže viem si spustiť viacej inštancií tej istej služby (viac tunelov na rôznych portoch), vie vyčistiť všetky procesy z danej skupiny procesov atď.