Názor k článku Nebojte se systemd: co to je a co umí? od Heron - 1. Od initu bych jako uživatel čekal Otázkou je,...

1. Od initu bych jako uživatel čekal

Otázkou je, zda je init tou správnou vrstvou, na které by se to mělo řešit. Máme virtuálky, máme kontejnery, ty si zapněte a vypněte, kdy potřebujete. Případně nevidím problém se relognout z gnome do kde a v terminálu si pustit service httpd start.

2. Není lepší jenom deklarovat "pro db server spusť a, b, c, d. D spusť v okamžiku, kdy a, b a c už běží." a neřešit, ve skriptu pro c, že parametr x daemona a musí být 7?

Tak především žádné takové složité závislosti nejsou v praxi potřeba. DB server si můžete pustit jako uživatel klidně příkazem pg_ctl start -D /data a máte to. Hromada démonů (a s nástupem systemd se to nemění), má ovládátko typu daemon_ctl.

V tomto případě je systemd v nevýhodě, protože zatímto do původního init skriptu byla možnost si vedle standardních start, stop, status apod. přidat třeba configtest. Takže admin příkazem service httpd configtest zkontroloval nastavení a příkazem service httpd reload jej potom nechal zavést. U systemd o tuto možnost přicházíte a je nutné pro kontrolu volat apachectl -t -D cosi ... (což je samozřejmně správné řešení).

3. Jako programátor nechci zabíjet čas psaním skriptu

Tohle čtu pořád dokola. Opravdu je taková zátěž, pro někoho, kdo napíše tisíce řádků kódu pro jeho skvělý program, pozměnit nějaký template? Stejně se s těmi rc skripty nic jiného nedělalo. Napsat akce pro start, stop, hotovo. Stejně se to píše i do systemd unity. Tak jaký je rozdíl. Za život jsem napsal mnoho rc skriptů, stejně tak několik unit pro vlastní potřebu, rozdíl v tom fakt nevidím. Ano, zápis unit souborů je přehlednější.