----- Original Message -----
From: "Matthew Melvin" <[EMAIL PROTECTED]>
To: "James" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, January 30, 2001 5:19 AM
Subject: Re: Killing "D" process
> Generally speaking a process in D state (disk) is 'in kernel' and theres
> nothing you can do about it. Sometimes you can attach strace to the
process
> and see what it's waiting on and give it what it wants (bring back it's
nfs
> mount for instance) but this is by no means reliable. lsof is also useful
> here, but sometimes you'll find it hangs for the same reason the process
> you're investigating is huhg.
>
Thanks for the quick suggestions guys!
ps auxf shows that it doesn't have a parent process (at least not reported
by ps). I don't have strace on that box, so will have to install that.
However lsof is on it, and if I am interpreting the results correctly it is
waiting on libc-2.2.so.
Anyway, I don't think it is really affecting anything but my load levels. I
noticed that they jumped a couple of days ago, and slowly went through all
of the processes that started in the time period in question (I log load
levels every six hours). This is another hazy area for me (lots of books
explain how to find the current load levels, but I've yet to find a clear,
concise explanation of how the numbers are generated). I *think* that
because this program comes up as 'waiting for input' it increments the load
levels by one. I don't notice any slowdown in normal operations however.
Anyway, here is the the ps auxf line if anyone is curious:
root 10454 0.0 0.2 1588 548 ? D Jan27 0:00
/sbin/modprobe -s -k block-major-7
-s=log to syslog, -k=autoclean, block-major-7=loop. I have no idea what it
is trying to do...
Cheers,
James
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
