[Debian]Hangende processen (status DN)

[mr_star]

Ik heb thuis een server staan die dienst doet voor internet delen, website hosten, file server, ...

Nu viel mijn oog vandaag op de load van deze pc: 43.5, 43.8, 43.10.
Daar zit dus iets niet echt goed.

En inderdaad, ps auxf gaf een 100-tal hangende processen. Het grootste deel van deze processen heb ik kunnen beëindigen. Maar nu blijven er nog 42 over die de status DN hebben.

code:

root     11154  0.0  0.1   3444  1136 ?        DN   Apr19   0:00 /usr/bin/find / ( -fstype nfs -o -fstype NFS -o -fstype proc -o -fstype afs -o -fstype proc -o -fstype smbfs -o -fstype autofs -o -fstype iso9660 -o -fstype ncpfs -o -fstype coda -o -fstype devpts -o -fstype ftpfs -o -fstype devfs -o -fstype mfs -o -fstype sysfs -o -fstype shfs -o -type d -regex \(^/tmp$\)\|\(^/usr/tmp$\)\|\(^/var/tmp$\)\|\(^/afs$\)\|\(^/amd$\)\|\(^/sfs$\) ) -prune -o -print0
root     12425  0.0  0.1   3444  1132 ?        DN   Apr19   0:00 /usr/bin/find / ( -fstype nfs -o -fstype NFS -o -fstype proc -o -fstype afs -o -fstype proc -o -fstype smbfs -o -fstype autofs -o -fstype iso9660 -o -fstype ncpfs -o -fstype coda -o -fstype devpts -o -fstype ftpfs -o -fstype devfs -o -fstype mfs -o -fstype sysfs -o -fstype shfs -o -type d -regex \(^/tmp$\)\|\(^/usr/tmp$\)\|\(^/var/tmp$\)\|\(^/afs$\)\|\(^/amd$\)\|\(^/sfs$\) ) -prune -o -print0
root     13475  0.0  0.1   3444  1132 ?        DN   Apr19   0:00 /usr/bin/find / ( -fstype nfs -o -fstype NFS -o -fstype proc -o -fstype afs -o -fstype proc -o -fstype smbfs -o -fstype autofs -o -fstype iso9660 -o -fstype ncpfs -o -fstype coda -o -fstype devpts -o -fstype ftpfs -o -fstype devfs -o -fstype mfs -o -fstype sysfs -o -fstype shfs -o -type d -regex \(^/tmp$\)\|\(^/usr/tmp$\)\|\(^/var/tmp$\)\|\(^/afs$\)\|\(^/amd$\)\|\(^/sfs$\) ) -prune -o -print0

Deze krijg ik dus met geen mogelijkheid gekilled. (ook niet met kill -9)

Daarnaast had ik al langer (een tweetal weken) 'last' van een load die altijd boven de 1 bleef omdat er een samba process hangt:

code:

maarten  17265  0.0  0.6  44152  4696 ?        D    Mar05   0:01 /usr/sbin/smbd -D

Ook deze krijg ik dus niet gestopt.

Heeft er iemand een idee hoe ik deze processn kan beëindigen en waarom deze processen blijven hangen?

Ik weet dat deze processen komen van de opdracht 'updatedb' die ik door cron ieder uur laat uitvoeren. Maar tot gisteren werkte alles nog gewoon hoe het moest.

Ik dacht in eerste instantie aan een dode schijf. Er zitten 2 sata schijven in, maar die zijn allebei gewoon te benaderen.

[zomertje]

Weet je zeker dat er niks mis is met de schijven?

[igmar]

Status D is een uninterruptable sleep, en da's in 99% van de gevallen disk IO. Een andere mogelijkheid is dat je kernel een segfault of een OOPS heeft gehad, in z'n geval geeft het currect proces ook een status 'D'.

[mr_star]

igmar schreef op vrijdag 21 april 2006 @ 15:43:
Status D is een uninterruptable sleep, en da's in 99% van de gevallen disk IO. Een andere mogelijkheid is dat je kernel een segfault of een OOPS heeft gehad, in z'n geval geeft het currect proces ook een status 'D'.

Ik kwam de betekenis van status D daarstraks toevallig tegen tijdens labo besturingssystemen Lijkt me dus dat die enkel te beëindigen is door te rebooten (vind ik zo'n typische windows oplossing...)

Ik begrijp dat er nu heel veel kans is dat 1 van mijn schijven niet meer te betrouwen is. Ik zal eens hdd-intensieve taken doen op elke schijf apart. Als er dan bij een bepaalde schijf een proces blijft hangen ken ik de boosdoener. (hopelijk is het niet mijn systeemschijf)

Weet er iemand misschien nog andere mogelijke oorzaken? Er is helemaal niets terug te vinden in mijn logs.

edit:
hdparm levert mij dit op:

code:

/dev/sda1:
 Timing cached reads:   2584 MB in  2.00 seconds = 1290.91 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device
 Timing buffered disk reads:  166 MB in  3.02 seconds =  55.05 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device

/dev/sdb1 geeft mij trouwens dezelfde melding. Ik dacht dat hdparm niet goed om kon gaan met sata schijven, dus ik zal voorlopig de schuld daar maar op steken. Tenzij iemand anders het beter weet

[ Voor 26% gewijzigd door mr_star op 21-04-2006 18:39 ]