Vlákno názorů k článku
Jádro 6.13 bude hlásit počet zaseklých úloh od RDa - Treba jednou peklo zamrzne a dockame se stavu,...

Treba jednou peklo zamrzne a dockame se stavu, kdy pujde uninterruptible sleep ukoncit, at uz soft, ze to odblokuje wait a vrati syscall, nebo hard, ze to rovnou zabije volajici proces.

To není tak jednoduché, protože v jádře jsou ve stavu D rozpracované datové struktury. A násilné ukončení by muselo provést úklid, jenže by se na něco mohlo zapomenout a vysledkem by byly poškozené datové struktury (tj. mnohem větší problém).

Navíc, když je něco dlouho v D, znamená to vážný problém. A vážný problém znamená, že starosti o zaseklé procesy má admin až úplně na posledním místě.

25. 11. 2024, 21:44 editováno autorem komentáře

Mno, kdyz si odmyslim HW problemy, tak nejcastejsi dlouhodobejsi D-cka, na ktera jsem vzdycky narazil, je upadlej NFS mount (kde je hard default), pripadne SMR disk, ktery prave dostal kramy a jal se zametat. Popr. pomala velka mmc spolu s hodne pameti (==hodne dirty cache)

V vsech trech pripadech budu doufat, ze nikoho (kernel ani distribuci) nenapadne ten automaticky reboot zapinat by default.

Tak muj D problem naposled s qemu nad loopdev byl takovej ze reboot ani nesel udelat. Tak nevim zda ten automaticky by na tom byl nejak lepe - nebo je to vynuceny hard-reset bez nejakeho rozumneho vypinani.

Vzdy je lepsi mit moznost zachranit co se da... a ten reset udelat rizene. Samoztejme se bavime vicemene o manualnim zasahu. Otazkou je, kolik lidi se s tim v realu bude sr*t... aneb tipuju, ze vetsina rovnou sahne po resetovacim cudliku.

Jasne, ono je totiz mnohem jednodussi tomu stroji proste vytrhnout kabel z elektriny, protoze to je tak jediny co se s tim da delat.

To vubec nedava smysl, co pisete. To potom uz nebude "neprerusitelny" spanek :) /s