Restartování a offline aktualizování Fedora Linuxu (diskuse)

[Jendа]

Vám někdy někomu spadly Xka kvůli updatu? Co se mi ale opravdu stalo bylo crashnutí systemd a následný panic:

Hejt: 2019-12-09 (Debian 10)

Za mých mladých let bylo možné za běhu přeplácnout rootfs, udělat sync a otočit to přes sysrq_trigger. To už teď nejde, protože systemd na rozdíl od původního jednoduchého initu, který se spustil a běžel, hrabe na disk a přečte si změněné knihovny (se kterými samozřejmě není kompatibilní) a spadne, což způsobí panic (protože spadne PID 1) - ještě než jsem stihl nový rootfs rozbalit.

[  498.581817] systemd-journal[230]: segfault at 1 ip 00007f622f593004 sp 00007ffe1d668410 error 4 in libsystemd-shared-241.so[7f622f55f000+147000]
[  498.595361] Code: 00 00 48 83 c0 17 31 c9 48 c1 e8 04 48 c1 e0 04 48 29 c4 4c 8d 4c 24 0f 49 83 e1 f0 48 83 bb 30 01 00 00 00 4d 89 cf 0f 84 e9 <02> 00 00 8b 7b 04 89 f2 4c 89 fe e8 fc 1c fd ff 41 89 c4 85 c0 0f
[  498.616493] systemd[1]: segfault at 1 ip 00007f737f681004 sp 00007fff50859190 error 4 in libsystemd-shared-241.so[7f737f64d000+147000]
[  498.628918] Code: 00 00 48 83 c0 17 31 c9 48 c1 e8 04 48 c1 e0 04 48 29 c4 4c 8d 4c 24 0f 49 83 e1 f0 48 83 bb 30 01 00 00 00 4d 89 cf 0f 84 e9 <02> 00 00 8b 7b 04 89 f2 4c 89 fe e8 fc 1c fd ff 41 89 c4 85 c0 0f

Message from syslogd@debian at Dec  9 00:02:09 ...
 kernel:[  498.616493] systemd[1]: segfault at 1 ip 00007f737f681004 sp 00007fff50859190 error 4 in libsystemd-shared-241.so[7f737f64d000+147000]

Message from syslogd@debian at Dec  9 00:02:09 ...
 kernel:[  498.628918] Code: 00 00 48 83 c0 17 31 c9 48 c1 e8 04 48 c1 e0 04 48 29 c4 4c 8d 4c 24 0f 49 83 e1 f0 48 83 bb 30 01 00 00 00 4d 89 cf 0f 84 e9 <02> 00 00 8b 7b 04 89 f2 4c 89 fe e8 fc 1c fd ff 41 89 c4 85 c0 0f
[  498.871929] systemd: 41 output lines suppressed due to ratelimiting
[  498.878622] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

Nicméně řešením fakt není zavádění Windows-like updatů, třeba taky protože to ztěžuje ten právě uvedený jiný usecase. Řešením je dělat kritický systémový software tak, aby se tohle nedělo.

[.]

A na dřevákách se netrhaly tkaničky, to byly libové časy. Nikdy nešlo přeplácnout rootfs tak, aby to na systém nemělo dopad. Ale jo, když ti tam nic moc neběží, tak to pak tolik nevadí. Zavádění offline updatů, aby se nerozkopal živý systém, samořejmě JE řešení.

[sdfgsdfg]

Ne, systemd je prasarna.

[little.owl]

Zaspal jste dobu, systemd wars jsou jiz davno za nami.

[plostenka]

Pred systemd slo vymenit za behu cely kernel a cokoliv jineho, jedine zmeny v GRUBu se projevily az po restartu (logicky). Vynuceni offline updatu je jen dalsi z rady priznani, ze systemd je nepatchovatelny antisystemovy hovnokod.

[little.owl]

Prepsat za chodu rootfs ci jakekoliv systemove dynamicke knihovny si koleduje o problemy. Pokud se z rozhledny kouknu jak to funguje, pak treba vymena dynamicke knihovny za chodu, po te co byla namapovana do adresoveho prostoru bezici aplikace, muze byt nedeterministicka zalezitost v podstate s nedefinovanym chovanim. Staci se podivat co se musi delat v pripade live patching kernelu, aby to fungovalo spolehlive. Ve vasem pripade to odskakala knihovna libsystemd-shared-241.so. Ono to jde v aplikaci udelat tak, aby se limitovaly dopady a zmensila pravdepodobnost provlemu, ale vetsinou zkoncite s SIGSEGV/SIGBUS a etc.

[plostenka]

vymena dynamicke knihovny za chodu, po te co byla namapovana do adresoveho prostoru bezici aplikace, muze byt nedeterministicka zalezitost v podstate s nedefinovanym chovanim.

Kdyz uz je namapovana, tak je v pameti a co je ulozeno na FS je ireleventni. Live updatu to neprekazi.

[little.owl]

Zalezi jak jste otevrel knihovnu (flags RTLD_*, lazy mapping etc.) a jak systemova knihovna pouziva mmap() ke cteni sdilene knihovny. Pokud si vybavuji, flag MAP_DENYWRITE je v Linuxu ignorovan, takze prepis se vam muze hned promitat do namapovani souboru.

[Pavel Píša]

Pokud update nejdříve rozbalí novu knihovnu do do jiného inode, tedy třeba souboru se jménem s přidanou příponou ".new" a pak provede atomický rename, tak pokud nedochází k nekompatabilní změně vstupních pod pod stejným soname a jménem na disku, tak v cel=m procesu updatu není okamžik, kdy by nově startovaný program nenastartoval právně a již běžící měl problém.

Unixové systémy a Linux VFS nemalí delete file, ale jen unlink. To znamená, že je jen odkaz na inode (soubor) smazaný z adresáře, stále se na něj může odkazovat jiný adresář a může být otevřený. Teprve až neexistuje žádný odkaz a všichni soubor zavřou (uvolní deskriptory/file struktury) tak dojde k jeho smazání.

Update dopadne většinou dobře i když se soubor nejdříve smaže a pak se balík rozbaluje. Ale zde je již okno, kdy nově spouštěná aplikace selže.

Pokud se existující soubor otevře, zkrátí a smaže, tak to prvavdu nedopadne dobře. Pokdu ho nezkrátíte a budete do něho zapisovat, tak při shared mapování se budou data měnit i přímo ve všech adresních prostorech na příslušných mapovaných stránkách. Linux plně využívá pagecace a opravdu dodržuje pravidlo, že aktuální data jsou oprvavdu jen na jednom místě v paměti a lze nad nimi provozovat atomické operace. Pak se časem stáhnou do backing store atd.. Nebo se z ní natahují , ale to jen v řípad, že ještě nejdou v pagecache. Taže read souboru, který je mapovaný opravdu čte to co ve stránce program mění programu pod rukama...

Je to rozdíl od Windows, kde update udělat za běhu nejde. Otevřený soubor nelze z historických důvodů. Ve FAT byly přímo servisní údaje o prvním clusteru a délce souboru přímo v položce adresáře. Odpojení od adresáře zmazáním položky zlikvidovalo místo, kde data byla a zároveň se s daným indexem mohl objevit soubor jiný. Linux tyto defekty DOSu mohl překrýt UMSDOSem, kdy se pak systém snažil nad špatným návrhem adresářů DOSu zařídit i korektní přejmenovávaní a linkování souborů. Pokud si pamatuji, tak NTFS je z pohledu datové struktury v pořádku, ale Microsoft se rozhodl v počátku neriskovat změnu chování a odlinkování otevřených souborů nedovolil. Pak to asi začala být i předpokládaný miss-featura a drží se toho dále. Takže systémové knihovny lze měnit jen tak, že se nahrají do seznamu přejmenování které se má stát při příštím startu systému a management isntallu musí být provedený v jádře před spuštěním první (i systémové) služby využívající mapované dynamické knihovny. Špatný design na začátku vede k hromadění chyb, install support v jádře atd...

U GNU/Linuxu je spíš problém, že dnes některé sestavení SW může vyžadovat opravdu tu konkrétní verzi knihovny, protože se vzájemné kombinování netestuje. Dále pak běžící službě zmizí třeba /usr/share adresář s její verzí a objeví se nový atd a tím, že dnešní systémové aplikace jsou závslé na různých interpreterech, jejich knihovnách možná i electronu a kdo ví čem všem, tak se musí od upgrade za běhu odcházet. Konzervativně nativně psané a kompilované služby lze implementovat tak, že přežijí a i tak se vetšinou server otočí a nechají se jen dobíhat klienti připojení do dřívější již z jemného prostoru/adresářoví struktury spuštěné verze aplikace. SSH je celkem komplexní a nemá s tím problémy...

Jinak hodně z rychlíku se zmiňuji o tm, jak funguje správa paměti a její propojení s pagecache a souborovými systémy v přednášce Pokročilé architektury počítačů – 06 (paměťový subsystém) (Preznetace v PDF). Přednáška je spíše o tom HW, není o operačních systémech a předmět zaměřený na open-source operační systémy, kde jsem se při zavádění chtěl věnovat opravdu stavbě otřených systémů až do základů jádra se na základě požadavků studentů změnil spíše na přehled a soft-skill a nakonec zrušil. Ale pro zájemce bych ho mohl nabídnout jako zájmový kroužek nebo kousky vytáhnout na OpenAlt, LinuxDays atd (Open Source Programování).

[little.owl]

Jasne, diky. Take jsem psal, ze pokud se pouzije unlink a rename, melo by byt v pohode.

[Jendа]

Prepsat za chodu rootfs ci jakekoliv systemove dynamicke knihovny

rsync to standardně zapíše vedle a přesune, takže otevřený soubor zůstane se starým obsahem. Považuji za spíše nepravděpodobné, nicméně nemohu vyloučit, že jsem to spouštěl s --inplace, pak vaše vysvětlení dává smysl. Spíš jsem si myslel, že došlo k zaradování se „jéj update! loadnu ho! BUM“, ale je pravda, že to nezní příliš pravděpodobně.

si koleduje o problemy

Tak já to pak neplánuju provozovat, okamžitě po doběhnutí rsyncu následuje reboot.

[little.owl]

Jak jsem psal vyse, zalezi jak je to namapovane pres mmap() a jak se to prepise - pokud se pouzije unlink a rename, asi by to melo byt v pohode - tusim, ze tak to dela install a interne rpm u dynamickych knihoven. Nicmene treba Firefox mi chronicky pada, pokud provedu jeho update na pozadi, to neni otazka jestli, ale kdy - takze nevim - ted bohuzel nemam cas se na to podivat.

[Jendа]

Firefox AFAIK spouští nové procesy-workery, a spadne protože je nekompatibilní jejich komunikace se zbytkem Firefoxu.

[little.owl]

Tak jsem ted chvili prohanel Firefox a ltrace a vypada to, ze loaduje knihovny, ktere predtim nemel namapovany v pameti a tak skutecne drive ci pozdeji zkonci po update s mixem nekolika verzi.

[RB]

Nejde jen o to, jestli kvůli tomu něco spadne nebo ne. Ale taky o to, že tím restartem člověk zajistí, že všechny aplikace a služby jsou restartované. Běžnému uživateli těžko budete vysvětlovat, že si má dotčené aplikace a služby restartovat. On si myslí, že aktualizace nainstaloval a je v suchu, zatímco dál jede na nezáplatovaných verzích.

Pokud je k dispozici i nadále dnf upgrade, nemám s offline updaty jako výchozí volbou problém. Oproti Windows je to podstatně méně otravné. Trvá to pár minut a nevyžaduje to několik restartů.

[R]

Debian na to ma needrestart.

[little.owl]

To neni totez, to je spise ekvivalent dnf needs-restarting. U Fedory dnf updgrade stahne rpm balicky a rebootuje do specialniho prostredi implementovaneho jako target systemd, kde se to bezpecne updatuje.