Vlákno názorů k článku
Dělá systemd Linux více složitým, náchylným k chybám a nestabilním? od Heron - Tak největší problém systemd je, že žádný jeden...

Tak největší problém systemd je, že žádný jeden systemd neexistuje. Takže sen mnoha diskutující před x lety, jak linuxu chybí jednotné rozhraní a jak se nedají psát init skripty pro 20 distribucí a jak to všechno systemd změní, jsou ty tam.

Dřív byl součástí systemd třeba nspawn, takže se dalo spolehnout na to, že všude kde je systemd, je i nspawn. Dneska je to oddělený balíček.

Součástí systemd je networkd, ale každá distribuce si tahá vlastní ovládátko sítě a networkd je masked. Totéž platí pro resolved, masked a co distribuce, to jiné řešení dns překladů.

Další věc je třeba timesyncd. By default vypnutý a každé distro si to řeší po svém. V debianu stačí odinstalovat ntpd a zapnout timesync. No, jenže když se stejný postup udělá na CentOS, tak synchronizace nefunguje. Proč? Protože CentOS nemá timesyncd a přes systemd příkaze timedatectl se ovládá ntpd. Na RHEL je potom chronyd.

Rozumím tomu, že si každá distribuce může zvolit defaultní programy, ale nerozumím tomu, proč "sjednocující prvek" linuxového světa musí každá distribuce ojebat po svém. V Debu to naštěstí ještě jde, standardně dávám pryč ntpd, network manager a ty ifupdown skripty a nastavím networkd, resolved a timesync. A nainstaluju nspawn (systemd-container). Nezblázním se z toho. Ale to, že CentOS/RHEL ty některé součásti systemd tam ani nemá, tak to mě fakt překvapilo.

Takže tolik k té jednotě.

A to nemluvím o zabugovanosti. O tom, jak za všechny chyby systemd může někdo jinej, o tom, jak snadno se to používá (narážím na to, že ini like pro psaní unit není tak úplně ini like - není nad design s důrazem na nejmenší překvapení).

Takže dřív se možná řešilo 20 různých dister, dnes se musí řešit 20 různých konfigurací systemd. Nevím, zda jsme si pomohli.

No ten můj komentář byl spíš rýpnutí do diskusí před x lety. Mnoho diskutujících nadávalo, že linux je roztříštěný a že systemd přinese jednotný systém a bude to všude stejné. Po pár letech se ukazuje, že ani systemd není všude stejný (a to dokonce ani na OS od firmy, která vývojáře systemd platí), takže ani na tu jednotnost se nelze spolehnout.

Jinak admini (nebo teda já, abych nemluvil za ostatní) chtějí především funkční programy. Myslím, že i tato diskuse ukázala, v čem je problém

RC skripty rozhodně nemusí mít 1000 řádků. Pokud mají, tak je něco špatně. S daným programem. Normální rc skripty mají start a stop (pokud programu nestačí poslat SIGTERM) a tím to prostě hasne. Většina skriptů v bsd jsou přesně této povahy. Start a šmytec. Tj do systemd unity stačí dát totéž do ExecStart a je to.

No jenže jak i tato diskuse ukázala, tak problém není ani tak v konkrétním rc systému, jako spíš v těch programech. Pokud program závisející na db se není schopen vyrovnat s tím, že db při jeho startu ještě neběží, tak je špatně napsaný. Protože s výpadkem spojení do db se musí vyrovnat i za provozu (nebo nevím, zda někdo skutečně restartuje všechny závislé aplikace jen proto, že na chvíli vypadlo spojení na db, já ne a nevidím nejmenší důvod to dělat).

A o tom případu enterprise aplikace, která se náhodně hroutí při paralelním startu ani nemluvím. Ale možná mám jiný slovník a slovo enterprise je synonymum pro: blbě napsaná.

A jak nastavujete síť? Přes konfigurák interfaces?

Vždyť to tam píšu. Používám systemd-networkd.

Omlouvat se není třeba. Mě se způsob zápisu nastavení sítě v networkd prostě líbí.

https://doc.heronovo.cz/2017-04-23-nastaveni-site-systemd.html

Je to ini-like, je to dostatečně jednoduché na napsání ručně a funguje to. Na rozdíl třeba od starých network-scripts z rhelu, kde bylo potřeba mít pro každou adresu vlastní soubor (nebo dělat ty šaškárny s číslováním), tak tady pro 30 IP prostě jen zopakuju 30x řádek Address a je to. Nebo sekcí route pro několik statických rout. Bridge se nastavuje snadno, bond taky (a to dost podobně).

S Network Managerem mám špatné zkušenosti, po páté přidané statické routě (přes nm-tui) už to prostě přestalo fungovat (až do restartu os).

Jinak já se snažím minimalizovat počet komponent v systému, tedy pokud je něco součástí systemd a lze to použít, tak to použiju. Nedělám to z lásky k systemd, to rozhodně ne, ale v některých věcech je to prostě jednooký král mezi slepými. Zrovna v případě té konfigurace sítě mě to tak připadá.

Samozřejmě, že dá. Doporučuju si udělat výlet třeba do FreeBSD. Je to příjemné osvěžení. Je to v shellu, skripty jsou krásně přehledné, rc skripty služeb jsou na pár řádků. Jde to.

To by mohlo vysvětlit složitost systemd

Tak složitost systemd je dána především tím, čeho všeho chce dosáhnout. V podstatě místo dlouho běžících programů (spuštěných jednou při bootu) jak bylo zvykem doposud, chce udělat systém postavený na velmi malých komponentách, které se budou spouštět v reakci na události. A systemd má prostředky na to, jak toho dosáhnout, včetně třeba mountů. Takže lze mít desítky aplikací, každou s vlastním oddílem pro data, který se připojí až je potřeba, tj před startem toho programu, který se nastartoval v reakci na nějakou událost. A toto celé mít třeba zavřené v konkrétním nspawn kontejneru. Lze to, v idle stavu se používá minimum prostředků a v provozním stavu se používá jen to, co je potřeba.

Jenže je tady několik problémů. Jednak nikde není (nebo ke mě se to alespoň nedostalo), uvedeno, čeho přesně chce systemd dosáhnout (takže cíl je potřeba jen odhadovat z toho, co je zrovna k disposici a jak jsou ty komponenty postavené) a podstatnější problém je ten, že chce změnit a totálně obrátit zavedený systém, který je postaven na zcela jiných základech.

Já osobně (ač jsem velký kritik systemd), nemám nic proti změně konceptu na událostní. Hromada malých komponent, aktivují se na jednotlivé události, lze dosáhnout vysoké paralelizace. Ostatně, spousta systémů se takto dávno navrhuje. Ale mají si to udělat na svém vlastním písečku. Mohli mít vlastní OS a představit vlastní konkurenční koncept.