Process Status D

webee · 02-11-2003, 05:22 PM

Hi:

What does the status D indicate when i run ps aux command?

If any process has status D (which i read means In disk or short term wait) is it something i should worry about?

I have an application written in C that sometimes gives me a seg fault. When I ran it with gdb, that process state is given as D.

Thanks for any input on this.

neo77777 · 02-11-2003, 05:28 PM

If you weren't lazy you'd do basic
man ps
and search for STATE

Code:

PROCESS STATE CODES
       D   uninterruptible sleep (usually IO)
       R   runnable (on run queue)
       S   sleeping
       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)

webee · 02-11-2003, 05:45 PM

Oh well. I have the Linux Administration Handbook and thought it was all I had to go on with. Thanks.

MasterC · 02-11-2003, 06:07 PM

Quote:

Originally posted by neo77777
If you weren't lazy you'd do basic
man ps

ouch!

I guess for a programmer or someone with any knowledge whatsover

Code:

   uninterruptible sleep (usually IO)

makes sense. But for me it doesn't. Could someone explain what that means, and more importantly, why I would even care whether something had a "D" on it or not?

Thank you

And if it's in a man page somewhere, I'd be happy if you'd just point me towards it

Cool

jonr · 11-09-2003, 12:14 PM

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!

tim1235 · 09-09-2004, 07:31 PM

I have a similar problem:

I was trying to mount a flash stick and it failed leaving processes in an Uniteruptable sleep state (D)
I tried to kill them with "kill -9 PID", but to no avail,

The only way I have found to get rid of these is to reboot, so anyone with knowledge of how to get rid of these would be greatly appreciated

rht7147 · 10-21-2011, 07:59 AM

I also faced the same problems. But another behaviour i noticed that process used to switched between s(sleeping) & D state.

Quote:

Originally Posted by tim1235

I have a similar problem:

I was trying to mount a flash stick and it failed leaving processes in an Uniteruptable sleep state (D)
I tried to kill them with "kill -9 PID", but to no avail,

The only way I have found to get rid of these is to reboot, so anyone with knowledge of how to get rid of these would be greatly appreciated

rht7147 · 10-21-2011, 08:00 AM

I also faced the same problems. But another behaviour i noticed that process used to switched between s(sleeping) & D state.

abisko00 · 02-11-2013, 01:12 PM

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:

http://stackoverflow.com/questions/1...process-states

Quote:

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.

heatfanjohn · 05-13-2016, 12:02 PM

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).

The command finally finished.

mostlyharmless · 05-13-2016, 04:20 PM

There's something terribly amusingly ironic about a necrobump on a thread about uninterruptible sleeping processes.

speedfixer · 06-06-2019, 01:23 AM

Searched and found this as best hint at what is happening.

Old, but relevant.

A particular compile process on my 3B+ PI goes into 'D' state. Several minutes, then comes out with job completed. So ... D can be a valid state.
Sadly, this is a tiny header only test compile, not a real program yet.

Still no explanation. My guess: in my case, lots of I/O and file locks in a terribly slow system.
The clocks and timers all still ticking.
When the system has to do its work, my process goes into this protected wait so it won't get terminated.

david

Stumbling · 07-08-2019, 05:03 PM

had the D status show up on writing to and SD card, something that should have been 15 minutes was taking over an hour plus.
The iostat command at least showed me that the card was being written too, however slowly. like .7 kb/s
Anyhow, the process did complete after about 2 hours.

Thanks for the tips!