systemd 248

Po čtyřech měsících vývoje od vydání verze 247 byla vydána nová verze 248 správce systému a služeb systemd (GitHub, NEWS). Z novinek lze zdůraznit systemd-sysext a systemd-cryptenroll.

31.3.2021 00:33 | Ladislav Hagara | Nová verze

Komentáře

[Jakub]

Děkuji ne, raději Windows.

[Pixel]

Má reakce

[VoDo]

Super pokrok nezastavis ikdyz v linux komunite to dost kulha :) Jako treba vejland kterej je beta uz asi deset let, ale mozna jednou to bude i fungovat!

[skunkOS]

Optimista

[_]

Wayland ani systemd mi nesmi do pocitace, to skutecne radeji jiny system, treba macos

[AsciiWolf]

Wayland ani systemd mi nesmi do pocitace

Proč? Věříš, že jsou tyto projekty skutečně tak špatné nebo jde o pouhou ideologii?

[sdf]

Je tohle pro tebe pouhá ideologie?

[AsciiWolf]

Z velké části ano. Používám GNU/Linux již dost dlouho na to abych pamatoval éru SysVinitu a problémů/bordelu, které okolo něj byly. Bohužel se nenašel nikdo, kdo by s tím něco rozumného udělal (a když už něco nadějného vzniklo, zabila to licence - viz například upstart - případně jiné důvody), až přišel aktivní Lennart a napsal systemd, které ačkoli bylo ze začátku docela problémové (a dodnes není ve všem zcela ideální), většinu z problémů SysVinitu nakonec vyřešilo a GNU/Linuxu dle mého názoru dost pomohlo. Samozřejmě chápu, že ne každému se tento "nový přístup", který systemd přineslo (a který byl již v té době běžný na mnohých komerčních *NIXech, například Macu či Solarisu), zamlouvá a konzervativní uživatelé z něj často nejsou příliš šťastní. Na druhou stranu právě tento přístup pomohl GNU/Linux kvalitou posunout dál.

[AsciiWolf]

Samozřejmě je to pouze můj vlastní názor, podložený zkušenostmi (uživatel, sysadmin), a nepopírám, že i ten "starý přístup" má určité své kouzlo. BSD je v tomto hezký příklad.

[j]

"většinu z problémů SysVinitu nakonec vyřešilo"

Fakt? A ktery?

---

Dete s tim guuglem dopice!

[cezz]

Napriklad ten, ze SysVinit nedokazal spolahlivo ukoncit sluzbu. Podla mna by cela diskusia mohla kludne skoncit uz tu, pretoze to je podla mna dost zakladna funkcionalita.

Alebo ten ze pri spusteni rucne a pri spusteni po starte mala sluzba ine premenne prostredia. Uplne klasicky problem bol ze init skript fungoval pri testovani v shelli, ale pri starte z "nejakeho dovodu" nie. Ten dovod bol pomerne jasny, ale tiez velmi zlozity na odhalenie.

Alebo ze nedokazal spolahlivo restartovat sluzbu ktora sa z nejakeho dovodu zastavila.

Alebo nedokazal spolahlivo indikovat ci sluzba vobec bezi.

Init skripty mali niekolko stran kodu, alebo mali neosetrene uplne zakladne edge cases.

V podstate jediny sposob ako upravit parametre startu nejakej sluzby bolo upravit ten skript a potom pri kazdom update balicka riesit aby tie upravy boli zachovane a zaroven aby boli zachovane zmeny na strane balicka.

Taka vec ako zavislosti medzi sluzbami boli riesene maximalne na urovni poradia v akom boli skripty spustane. Jednak to bolo pomale a tiez to casto nefungovalo lebo sluzba nebola realne funkcna dlho po tom co init skript uspesne skoncil.

Zavislosti typu "dostupna siet" alebo nedaj boze "pripojeny sietovy filesystem" boli prakticky neriesitelne SysVinitom.

Parallelny start viacerych sluzieb neexistuje. Mozno to bolo v poriadku v roku 2000, ale teraz ma aj najlacnejsi laptop na alze dve jadra a disk ktory nema problem s random seek time.

Nepamatam sa ze by niekedy init skript nejakym sposobom riesil obmedzenie spustaneho procesu - veci typu limit na alokaciu RAM, pristup k castiam filesystemu, sieti a podobne. Vsetko toto vyzadovalo upravu skriptu. (viz vyssie) Systemd ti nie len ze umoznuje pomerne jednoducho take obmedzenia pridat ale vela programov uz priamo v balicku ma nastavene ake take limity pre danu sluzbu - pretoze je to velmi jednoduche.

SysVinit skripty boli casto *velmi* specificke pre danu distribuciu. Trochu ina premenna PATH alebo trochu ine umiestnenie standardnych systemovych utilit a skript nefungoval. Skripty ktore to mali osetrene obsahovali tonu "zbytocneho" kodu ktore clovek musel precitat a logicky vyhodnotit aby zistil preco sluzba po boote nenabieha.

Urcite by som este kde co vedel pridat, keby som poriadne pospominal, ale sam za seba musim konstatovat, ze som rad ze tieto veci uz riesit nemusim.

[j]

Jo, tak to urcite ... ubermegalol ...

Nejzasadnejsim ukolem initu je restartovat crashujici servisy ... o kterych vlasne nevi jestli crashly. Tys asi vzivote nevidel vubec zadnej system ze? Ten tvuj systemd nedela nic jinyho, nez ze ten kilometrovej script spusti. A proc? Protoze ta vec trebas potrebuje overit nejaky minimalni podminky, za kterych je ochotna nastartovat, aby pritom nedoslo k nejakymu pruseru na tema likvidace dat.

Kdyz neco crashne, tak to crasne proto, ze je neco spatne, a to neco je treba vyresit. Spustit to znova muze leda vul. Nemluve o tom, ze kdyz chci hlidat jestli neco bezi, tak to systemd samozrejme neumi, protoze umi tak maximalne to, co kazdej jinej init - zjistit ze se servisa odporoucela slusne.

Zato se mi jeste nikdy s nicim jinym nestalo, ze bych kvuli aktualizaci musel restartovat celej system, nebo ze by mi kvuli bugu v logdemonovi nastal kernel panic.

Paralelni start je naprosta picovina, ktera start nekolikanasobne zpomali, a navic vede k tomu, ze je v logu neanalyzovatelnej bordel.

Nejvetsi velepicovina kterou pak pises je, ze to resi systemd, protoze je tu nejmin 10 dalsich initu, ktery umej totez a mnohem vic, a neni snima problem s tim, ze se serou naprosto do vseho, a ze kvuli nim crashne celej system.

Kupodivu, nastaveni initu je specificky pro kazdou distribuci, protoze kazda je jina, divny ze?.

Pricemz jeste musim zminit ty uberflikulinsky kokotiny jako ze to "jako" nastartuje servisu ale ona ve skutecnosti vubec nebezi, takze kdyz se na ni nekdo pokusi pripojit, tak mu to failne, protoze soudruh lennart ji az v tuhle chvili zacne startovat takze mozna za 20 minut uz i pobezi ... lol.

---

Dete s tim guuglem dopice!

[cezz]

1) Reagoval som na tvoju otazku slusne zoznamom veci ktore si myslim, ze SysVinit nezvlada a Systemd robi lepsie. Napisal som to normalne bez vulgarizmov a osobnych urazok a ocakaval som diskusiu na podobnej urovni.

2) Nemam pocit ze vies o com pises - to nemyslim ako urazku, ale ako fakt ze mi diskusia s tebou nema co ponuknut.

Myslim, ze som dostatocne vysvetlil, preco v tejto diskusii s tebou nebudem pokracovat.

[mirec]

Tak v prvom rade proti sysvinit-u nič nemám, ale init skripty v štýle debianu sú humus najvyššieho stupňa.

Na serveri si hostujem redmine a gitlab. Redmine s vlastným systemd unitom, ak ho zabije OOM killer ľahko sa reštartuje, nikdy som s nim nemal problém. Gitlab sa spúšťa dodávanými skriptami. Ani sa nepamätám kedy som ho videl naštartovať tak, že aj indikoval, že je naštartovaný. Vypnutie je kapitola sama o sebe keď za sebou necháva bežiace procesy, kvôli ktorým sa už nedá znovu naštartovať. Samozrejme po zabití OOM sa nedokáže nštartovať.

Utilitka start-stop-daemon je extrémne nebezpečný a nespoľahlivý humus. Ok, ono to funguje na nejaké jednoprocesové služby, ktoré sa forknú a zapíšu si pid. Čokoľvek iné je nespoľahlivé. Také prípady ako keď služba nezapisuje svoj pid a má iný progam name než binárku nedokáže vyriešiť vôbec a pri pokuse o ukončenie start-stop-daemon jednoducho zostrelí nejaký proces s podobným program name, ale nie ten, ktorý má reálne zostreliť.

[cezz]

a když už něco nadějného vzniklo, zabila to licence - viz například upstart

Upstart sa postavil niekde medzi Systemd a SysVinit takym sposobom, ze to naoko vyzera ako pomerne moderny init, ale v reali je to len trochu lepsie organizovany SysVinit bash skript. Je mozne ze tomu nejako uskodila aj licencia, ale podla mna bol proste dost odlisny aby sa clovek musel ucit nove veci, ale zaroven neriesil vela starych problemov aby to usilie stalo za to.

a dodnes není ve všem zcela ideální

Za mna osobne je najvacsi problem, ze Lennart (a ludia okolo Systemd) su az prilis konzervativni. Systemd ma kopec nastaveni ktore priamo v dokumentacii odporucaju nejako nastavit ale napriek tomu je default opacny, postaveny velmi konzervativne v snahe reflektovat ako to bolo kedysi. Veci ako PrivateTmp, PrivateDevices, ProtectClock alebo vsetky ProtectKernel* podla mna mali byt by default zapnute, lebo pocet sluzieb ktore to nejakym sposobom nepriaznivo obmedzi je absolutne minimum. Ale mam pocit, ze sa proste bali toho ze im bude nejaky Frantisek Mytotakrobime posielat nahnevane bugreporty, ze bol zvyknuty prevadzkovat sluzbu s nejakou tou race condition zranitelnostou a ze si ju teraz musi explicitne vyziadat s PrivateTmp=false..

[_]

Ano jsou špatné. Waylandu chybí esenciální featury a systemd je mrdka, díky které ztrácím kontrolu nad počítačem.

[Jendа]

Waylandu chybí featury. Zlepšuje se to, jak to lidi postupně implementují, ale pomalu.

systemd unity mají příšerné defaulty způsobující nedostupnost když se něco pokazí, neskipnutelný 90s/5min timeout, nejde z toho vyrazit co vlastně unita spouští a kde se to rozbilo (srovnej spuštění init skriptu přes bash -x) a pak mám třeba WTF bizarní situaci kterou jsem ale ještě nezkoušel deteministicky zreprodukovat, že když za běhu přeplácneš knihovny journalu nekompatibilní verzí, tak se je to pokusí reloadnout a PID 1 (proboha proč) hodí držku což udělá kernel panic.

[j]

Neboj, on fungovat zacne ... az do nej naimplementujou vsechno co umej Xka. A pak zas prijde nejakej frikulin a zacne vykrikovat, jakej je to neprehlednej a nespravovatelnej bordel.

---

Dete s tim guuglem dopice!

[michich]

systemd-cryptenroll a nové funkce v systemd-cryptsetup se mi moc líbí. Hned jsem je využil.

[Jardík]

Ta šmejďárna systemd neumí dodnes ani načíst environment proměnné, které nejsou v utf-8, nebo obsahují kontrolní asci znaky.

[cezz]

Seriozne by ma zaujimalo aky ma toto use case.