Home » Linux » Process permanently stuck on D state [closed]

Process permanently stuck on D state [closed]

Posted by: admin November 30, 2017 Leave a comment


I have an issue with some processes stuck in a D state on Ubuntu 10.04.3 LTS.

They have been in this state since Nov the 5th (today being December 6th). I understand these are uninterruptible sleep states often related to waiting for data from hardware such as a hard disk. This is a production server so rebooting is a very last resort, is anyone able to shed any light on what these processes might be?

This is the output for the D state items from ps -aux

www-data 22851  0.0  0.0      0     0 ?        D    Nov05   0:00 [2637.64]
www-data 26306  0.0  0.0   4008    12 ?        D    Nov05   0:00 ./2.6.37
www-data 26373  0.0  0.0   4008    12 ?        D    Nov05   0:00 ./n2
www-data 26378  0.0  0.0   4008    12 ?        D    Nov05   0:00 ./n2

This is output of ps axl | awk '$10 ~ /D/' for a little more info.

0    33 22851     1  20   0      0     0 econet D    ?          0:00 [2637.64]
1    33 26306     1  20   0   4008    12 ec_dev D    ?          0:00 ./2.6.37
1    33 26373     1  20   0   4008    12 ec_dev D    ?          0:00 ./n2
1    33 26378     1  20   0   4008    12 ec_dev D    ?          0:00 ./n2

Is there a way to kill these? Does having processes in this state when rebooting cause any issues?


This is the dreaded un-interruptible (TASK_UNINTERRUPTIBLE) state of a process. This is the state where the process doesn’t react to signals until what it started to wait for, gets done.
Unfortunately it is a necessary evil. See here and here What is an uninterruptable process?.

My answer is to reboot the system.
Do rebooting cause any issues ?
Hard to tell, it may it may not. The process which is in the D state may have to do some crucial updates which it wont if you reboot.
If you really cant afford to reboot, try to find the disk on which the process is waiting and see if the disk is working fine by opening, closing, reading/writing into it


No – you cannot kill them, period. kill -9 does not work either. And it is not kernel bug, it is by design. All signals are blocked until those processes leave the D state. They either leave the D state or the system gets rebooted. No, rebooting does not have any problem with these guys.

The usual culprits for this kind of problem are removable media devices like a cdrom. The device may be defective or somebody found a way to do something stupid.