How to stop 'uninterruptible' process on Linux?

I have a VirtualBox process hanging around which I tried to kill (KILL/ABORT) but without success. The parent pid is 1 (init).

top shows the process as D which is documented as "uninterruptible sleep".

strace shows up nothing.

How can I get rid of this? It prevents me from unloading the VirtualBox kernel driver to load a newer one.

Simple answer: you cannot.

Longer answer: the uninterruptable sleep means the process will not be woken up by signals. It can be only woken up by what it's waiting for. When I get such situations eg. with CD-ROM, I usually reset the computer by using suspend-to-disk and resuming.

Killing an uninterruptible process succeeds, it just doesn't do so immediately. The process won't disappear until it actually receives the signal. So sending a signal alone is not enough to get rid of the process, you also have to wake it up from uninterruptible sleep.

Tanel Poder has written a great guide to analyse D state processes. It is very typical that this state is caused by incomplete I/O, e.g. network failure. slm has posted some very useful pointers on superuser how to unjam the network I/O, and also about the problem itself.

Personally, when dealing with Windows on VirtualBox, and even with wine, I often run into this problem because of a cdrom I/O that never completes (I guess its some sort of disc presence check). ATA devices can be reset, which likely will unjam the process. For instance, I'm using the following little script to reset both my optical drives, unjamming the processes they are blocking:

echo 1 > /sys/block/sr0/delete
echo 1 > /sys/block/sr1/delete
echo "- - -" > /sys/class/scsi_host/host7/scan

The D state basically means that the process is waiting for disk I/O, or other block I/O that can't be interrupted. Sometimes this means the kernel or device is feverishly trying to read a bad block (especially from an optical disk). Sometimes it means there's something else.

The process cannot be killed until it gets out of the D state. Find out what it is waiting for and fix that. The easy way is to reboot. Sometimes removing the disk in question helps, but that can be rather dangerous: unfixable catastrophic hardware failure if you don't know what you're doing (read: smoke coming out).

I recently encountered a process in D state on a remote server and would like to clarify that a hard reboot or power cycle is needed to remove the process.

Don't try a soft reboot until you have exhausted all other options. For example, you can try freeing up whatever resource the process is hanging on. A soft reboot might give you a system that is partially shut down and will no longer respond to ssh, but won't reboot because it is hung trying to terminate the uninterruptible process.

As others have said, an uninterruptable process is a process which is stuck in a kernel function which cannot be interrupted (usually it is waiting for some I/O operation). See this answer for a detailed description.

Apart from restarting the computer, I had success bringing some processes out of the D state by flushing linux VM caches:

kill -9 {process_id}
sync
echo 3 | sudo tee /proc/sys/vm/drop_caches

This did not seem to affect system stability, but I'm not a systems programmer and not sure what unintended consequences this might have.

---

Edit:

According to the kernel docs, drop_caches appears to be reasonably safe in a development environment.

> drop_caches > > Writing to this will cause the kernel to drop clean caches, as well as > reclaimable slab objects like dentries and inodes. Once dropped, their > memory becomes free. > > To free pagecache: > > echo 1 > /proc/sys/vm/drop_caches > > To free reclaimable slab objects (includes dentries and inodes): > > echo 2 > /proc/sys/vm/drop_caches > > To free slab objects and pagecache: > > echo 3 > /proc/sys/vm/drop_caches > > This is a non-destructive operation and will not free any dirty objects. > To increase the number of objects freed by this operation, the user may run > `sync' prior to writing to /proc/sys/vm/drop_caches. This will minimize the > number of dirty objects on the system and create more candidates to be > dropped. > > This file is not a means to control the growth of the various kernel caches > (inodes, dentries, pagecache, etc...) These objects are automatically > reclaimed by the kernel when memory is needed elsewhere on the system. > > Use of this file can cause performance problems. Since it discards cached > objects, it may cost a significant amount of I/O and CPU to recreate the > dropped objects, especially if they were under heavy use. Because of this, > use outside of a testing or debugging environment is not recommended. > > You may see informational messages in your kernel log when this file is > used: > > cat (1234): drop_caches: 3 > > These are informational only. They do not mean that anything is wrong > with your system. To disable them, echo 4 (bit 3) into drop_caches. >

new here and not that experienced, but I had the same issue where I could see my processes going into uninterruptible sleep (D state) when I checked their status using htop. For some reason,

kill -9 <pid>

worked for me. Maybe you can try the same.

Edit: the detailed answer is up there by ostrokach (which I didn't see).