Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you weren't lazy you'd do basic
and search for STATE
PROCESS STATE CODES
D uninterruptible sleep (usually IO)
R runnable (on run queue)
T traced or stopped
Z a defunct ("zombie") process
For BSD formats and when the "stat" keyword is used, additional letters may be displayed:
W has no resident pages
< high-priority process
N low-priority task
L has pages locked into memory (for real-time and custom IO)
I had xcdroast fall into "uninterruptible sleep" when I tried to include files from a mounted hard drive in the list of files to copy to my new CD-DVD+R burner (which I can only use for CD burning as yet, not DVD).
I'd never knowingly seen the "D" status symbol before, and found out what it meant, could not kill the process by any means, finally rebooted; tried the experiment again--ended up rebooting three or four times. Searched on Google, found only that people seem to have to reboot and that the problem MAY be due to a deficiency in the kernel design. At which point I was in way further over my head than before. I'm afraid there's not much I can do to help with kernel design...
If anybody reads this and knows of a way to avoid rebooting when a process goes into uninterruptible sleep, please post!
I know, this thread is old, but the initial question remained unresolved. Since I was looking for this information myself and this thread was the first hit on Google, I would like to quote the second-best hit here:
While waiting for read() or write() to/from a file descriptor return, the process will be put in a special kind of sleep, known as "D" or "Disk Sleep". This is special, because the process can not be killed or interrupted while in such a state. A process waiting for a return from ioctl() would also be put to sleep in this manner.
An exception to this is when a file (such as a terminal or other character device) is opened in O_NONBLOCK mode, passed when its assumed that a device (such as a modem) will need time to initialize. However, you indicated block devices in your question. Also, I have never tried an ioctl() that is likely to block on a fd opened in non blocking mode (at least not knowingly).
How another process is chosen depends entirely on the scheduler you are using, as well as what other processes might have done to modify their weights within that scheduler.
Some user space programs under certain circumstances have been known to remain in this state forever, until rebooted. These are typically grouped in with other "zombies", but the term would not be correct as they are not technically defunct.
So unfortunately it does not tell me whether my perl script for indexing a 30G database is after 3 days still functioning or waiting for input that will never ever come.
FYI, you can use the iostat command to see if I/O is happening. If there isn't any I/O going on then I would say that the "D" process is probably never going to complete. If there is I/O going on then it could be for the process that is in a "D" status.
I had a command in a "D" status that was unpacking a dep package. iostat on another terminal showed that my I/O device was running very slow (hundreds of milliseconds of service and await time).