On 23.3.2021 15:23, Miroslav Lachman wrote:
Proces je podle ps zaseknuty ve stavu D, coz je "process in disk (or other short term,
uninterruptible) wait".
No, a podstatne je, ze proces je "in-kernel". A v te chvili s nim
opravdu nejde nic udelat, protoze "neco" by se muselo udelat s jadrem
systemu a jedine relevantni "neco" je reboot. A dokonce i s tim mohou
byt nekdy problemy.
Uz minule jsem podezrival nejakou chybu filesystemu
Neni to zcela vylouceno, ale nemyslim si to. Tohle byva problem hloub,
na urovni disku jako takoveho. Nejaky pozadavek na disk, jehoz vyrizeni
(nikoliv nutne uspesne) trva chvili zde trva "donekonecna".
Problem disku, radice, ovladacu (ve vztahu ke konkretni HW konfiguraci).
A ted je otazka, jak tenhle problem priste resit? Tedy jak zjistit, na cem presne se to zasekne?
Coredump celeho systemu a nasledne narocna prace s kernel-debuggerem.
Neni to nemozne, ale velkou sanci ti nedavam.
Zkusil jsem na ten proces pustit ktrace -p 63940 a to same s truss, ale nic to
nevypise.
Kdyz uz proces v tom stavu je, je pozde.
problem je podle vseho na root partition. Tam se ale zasekava na cteni v ruznych
oblastech. Nejde precist /boot/ (cast obsahu vypise, ale pak se
zasekne), zasekne si i pri obycejnem "ls /mnt". Opet v neprerusitelnem
stavu.
Hypoteza: problem disku pri praci s konkretni oblasti
a) Misto pokusu se ctenim na urovni FS cti pomoci dd fyzicky disk.
b) Nainstaluj si smartctl a zkus vycist interni log disku jakoz i
S.M.A.R.T. parametry, proved "-t long" test (v dobe nizsiho provozniho
zatizeni disku).
Pokud slo o jednorazovou udalost a vyctene udaje nebudou vzbuzovat
podezreni, ze disk je ve spatnem stavu, pak to lze prejit jako "nahodnou
chybu". Pokud udaje disku nebudou uklidnujici nebo se situace bude
opakovat, je na miste zacit premyslet o (preventivni) nahrade komponenty.
Dan
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
