systemd 242

Byla vydána verze 242 správce systému a služeb systemd (GitHub, NEWS). Přibyla například podpora L2TP (Layer 2 Tunneling Protocol) nebo XBOOTLDR.

11.4.2019 22:11 | Ladislav Hagara | Nová verze

Komentáře

[sid]

myslim, ze kedze uz ziadne 100+ diskusie (spamy) ohladom systemd nie su zjavne nastal cas aby bol nahradeny niecim novsim aby sa tu mohlo rozbehnut dalsie kolko bitky o to aky je povodny init super (miesto init dame systemd) :)

[Jenda]

jenze systemd neni super

jenze systemd je super

[2017]

systemd je super, experimentalne implementuje gitd. nemusim nic resit a mam git repozitar jako systemd sluzbu.

[_]

Pro korporátní jelito mozna

[Roman]

Systemd je super, resi spoustu problemu a nedostatku SysV initu. Zkuste si napriklad udelat sysv init script, ktery restartuje crashlou sluzbu. V systemd unit file je to jeden atribut. Zkuste izolovat sluzbu - chroot? Prosimvas... dnes mame namespaces a cgroups. Doba pokrocila, jsou nove moznosti a na to mame novy init. Tak uz se ho konecne naucte pouzivat nebo jdete delat jiny job - je napr. nedostatek instalateru a dorucovatelu, tam je to porad dokola, hasak stejny jak pred 100 lety...

[Franta Hanzlík]

SysV init není jediný init a restart krachlé služby (je otázka, zda je správné jej řešit jejím restartem) není věc, která by ospravedlňovala roztažený nemodulární paskvil jako je systemd. To, že systemd spoustu problémů řeší (úžasné je, že výsledkem jsou služby a řešení, které už jsou implementované a často podstatně lépe), ve výsledku za těch posledních osm let, co je v distribucích, znamená hlavně to, že se v Linuxu objevil prvek významné nespolehlivosti a nestability, s chováním měnícím se od verze k verzi jinak. Osm let vrtochů téhle nekoncepční sračky - to je fakt pokrok.
Zrovna předevčírem jsem čekal na restart vzdálené mašiny skoro tři hodiny - a během té doby si představoval, co ten úžasný systemd musí vše řešit, aby se mu to konečně podařilo...

[xkucf03]

SysV init není jediný init a restart krachlé služby (je otázka, zda je správné jej řešit jejím restartem) není věc, která by ospravedlňovala roztažený nemodulární paskvil jako je systemd.

S tím nemodulárním paskvilem souhlasím, už jsem se tu o tom několikrát rozepisoval.

Na druhou stranu systemd má některé zajímavé vlastnosti, které jsem jinde neviděl. Jak jsou na tom jiné init systémy se socket activation? Tzn. init resp. super-server naslouchá a předává FD službám, které spouští. Tohle umí i xinetd, ale jen pro TCP a UDP – ne pro unixové doménové sokety. Umí to nějaký jiný systém i pro ně?

Další pozitivní vlastnost jsou deklarativní a přehledné konfiguráky. Možná by šlo systemd reimplementovat nějak jednodušeji a čistěji a převzít jeho formát konfiguráků, nebo aspoň udělat konvertor. Pokud někomu vadí systemd fakt hodně, tak tohle může udělat.

[Heron]

Jak jsou na tom jiné init systémy se socket activation?

To nevím, ale jedna věc ohledně socket activation mě docela štve. Že to nejde vypnout, ale stále mít možnost zachovat předání socketů. SD umí předat unix socket a poslat to jako stdin do procesu (což je prostě super funkce, některé programy se nechají ovládat na stdin), ale musí tam být socket activation. Takže se stává, že služba je vypnutá (má být vypnutá), a pokud někdo něco pošle do socketu, tak se zapne. Jako dá se s tím žít, ale mohlo by se to oddělit od sebe (tj vypnout socket activation, ale stále mít předávání socketů do procesu).

[xkucf03]

Takže se stává, že služba je vypnutá (má být vypnutá), a pokud někdo něco pošle do socketu, tak se zapne.

Když dám:

systemctl stop xxx.socket

tak unixový soket sice nezmizí, ale nejde se na něj připojit (Connection refused) a pokus o připojení nezpůsobí start služby. Ale když zastavím jen xxx.service nebo xxx a ne xxx.socket, tak pokus o službu nastartuje.

SD umí předat unix socket a poslat to jako stdin do procesu (což je prostě super funkce, některé programy se nechají ovládat na stdin)

Hezké je, že tohle podporuje i Java, takže v ní jde dělat služby naslouchající na unixovém soketu i bez jakýchkoli knihoven (dřív jsem myslel, že jen se standardní knihovnou nejde). Ale přes System.inheritedChannel() se lze dostat na ten soket předaný přes FD 0. A může to být jak serverový soket, na kterém si v javě voláš accept() a přijímáš jednotlivá spojení, tak již navázaný soket s konkrétním klientem, tak i datagramy. Xinetd umí oboje, ovšem jen pro TCP a UDP (ne pro unixové sokety). Zkusil jsem si napsat i „zavaděč“ v C, které vytvoří doménový soket, nastaví ho na FD 0 a pak přes execv() spustí Javu v témže procesu – a to funguje dobře, takže tohle jde dělat i bez systemd.

Systemd ale umí předávat i více soketů – dává je pak na vyšší FD a je k tomu sada funkcí, přes kterou zjišťuješ, kolik FD ti předal a který je který.

[Heron]

To, že systemd spoustu problémů řeší (úžasné je, že výsledkem jsou služby a řešení, které už jsou implementované a často podstatně lépe), ve výsledku za těch posledních osm let, co je v distribucích, znamená hlavně to, že se v Linuxu objevil prvek významné nespolehlivosti a nestability, s chováním měnícím se od verze k verzi jinak. Osm let vrtochů téhle nekoncepční sračky - to je fakt pokrok.

To jednak, ale hlavně se (poměrně překvapivě) příliš nekoná ani to sjednocení. Hromada příznivců systemd před lety tvrdila, že po systemd se vyřeší "problém" s rc skripty a autoři programů už nebudou muset dělat rc skripty pro všechny možné (asi tak 3) init systémy a bude jen systemd unita. Stav tomu rozhodně neodpovídá a když už se k programu dodává systemd unita, tak stejně volá jakýsi pahýl původního rc skriptu. Ale většina služeb je dnes stále přes rc skripty a unity se vytváří generátorem v systemd. (Což přináší další problémy.)

Také bych čekal vývoj směrem k rozdělení programů na menší části a jejich dynamické volání ve chvíli, kdy jsou potřeba. Systemd umí socket activation a další způsoby spouštění "on demand", ale nemám pocit, že by se to nějak intenzivněji používalo. Přitom pokud by někdo systemd vzal skutečně vážně a využil by všech jeho vlastností dynamického spouštění služeb, tak může vytvořit desítky mikroslužeb, které se budou dynamicky spouštět a vypínat, místo původních monolitů. Nic takového se nestalo. Sám jsem si nastavil socket activation tam, kde se dodávala příslušná unita a i třeba ssh už roky spouštím jen takto. + další moje bastl služby na různé drobnosti.

Takže systemd se prosadil (někde i na sílu), ale že by se stalo něco podstatného se říct nedá. Dokonce jsme se nezbavili ani balíků, které si služby řeší sami. Takže rc skript spustí jen další rc službu a ta si řeší další služby po vlastní ose. Třeba Gitlab-CE. Přitom systemd nabízí všechno, co tohle potřebuje. Ale i tak si to stále tahá s sebou vlastní rc systém. Divné.

Zrovna předevčírem jsem čekal na restart vzdálené mašiny skoro tři hodiny - a během té doby si představoval, co ten úžasný systemd musí vše řešit, aby se mu to konečně podařilo...

Řešil jsem něco podobného. Zálohuju desktopy pomocí BackupPC (přes ssh, resp rsync). Občas se stroj podezřele dlouho vypínal, systemd ani nepíp a jen čekal při vypínání služeb. Po x minutách naskočilo úspěšné vypnutí session-0. On bere přihlášení na ssh jako usera a čeká, až mu doběhnou všechny procesy. Místo, aby to zabil.

[Heron]

Zkuste si napriklad udelat sysv init script, ktery restartuje crashlou sluzbu.

Před tímto jsem už před lety varoval a několikrát se pohádal s Jirsákem. Automatický restart služby po "crashi" rozhodně není nic, co by se mělo používat nebo doporučovat. Zdravé služby nepadají. Už jen to, že to nikdo za ty roky SysV nepotřeboval o něčem vypovídá (a prostředky samozřejmě byly, i starý init umí respawn). Náhle se to objevilo v systemd, hromada tutoriálů na psaní unit na to poukazuje a za chvíli se z toho stane standard (v některých případech už dnes). Takže se snižuje tlak na to napsat službu správně (aby nepadala) a místo toho se řeší, jak ji zrestartovat.

Zkuste izolovat sluzbu - chroot? Prosimvas... dnes mame namespaces a cgroups.

Kontejnery jsou tady mnoho let. Déle, než systemd. Ostatně i ty namespaces a cgroupy. To nepřišlo se systemd. Systemd to začal je intenzivněji používat.

[xkucf03]

Kontejnery jsou tady mnoho let. Déle, než systemd. Ostatně i ty namespaces a cgroupy. To nepřišlo se systemd. Systemd to začal je intenzivněji používat.

+1 Na druhou stranu ale mít možnost to jednoduše deklarativně nakonfigurovat mi přijde fajn a je to rozhodně úkol pro init systém. Na rozdíl třeba od konfigurace sítě, NTP, podsvícení displeje a dalších věcí.

[j]

Normalni sluzby necrashujou, a jen spravce kterej ze zove hovadem neco takovyho automaticky restartuje.

Nehlede na to ze ta sracka pochopitelne nepozna, a nemuze poznat, jestli ta sluzba bezi nebo ne. Pokud se "slusne" neukonci.

[ehmmm]

Nehadejte se. Myslim, ze kdo chce, ten systemd ma. A kdo ne, ten se muze alespon v Debianu pomerne snadno vratit k sysvinit.

[Petr Ježek]

K alternativám systemd se může vrátit každý v každé distribuci, pokud ví, co dělá a není klikající automat. Já si bv Archu na systemd nemám proč jakkoli stěžovat, využívám jeho předností.

[Bluebear]

Problém je to pro BFU, kteří se kvůli systemd často vrací k Windows.

[Marián Kyral]

Teoreticky. Prakticky se mu odinstaluje většina balíků, protože jsou na systemd závislé. Takže odinstalovat to nejde, jen deaktivovat.