访问cifs的进程处于D状态

 

it's in uninteruptable sleep and basically can't be killed. "D" processes are generally waiting on I/O from a device. Since the kernel has allocated memory for the I/O operation in the process address space, if you killed the process then the device would write into memory that was no longer valid, and that would be a very bad thing. So the kernel won't let you kill the process.

If these processes are doing I/O on an NFS or Samba share that's gotten screwed up, you're basically out of luck unless you can remount the share in working order. With NFS at east, you can mount it with soft and intr which will stop processes from hanging forever in the "D" state if something goes wrong with the connection.

 

 

An uninterruptible process is a process which happens to be in a system call (kernel function) that cannot be interrupted by a signal.

To understand what that means, you need to understand the concept of an interruptible system call. The classic example is read(). This is a system call that can take a long time (seconds) since it can potentially involve spinning up a hard drive, or moving heads. During most of this time, the process will be sleeping, blocking on the hardware.

While the process is sleeping in the system call, it can receive a Unix asynchronous signal (say, SIGTERM), then the following happens:

• The system calls exits prematurely, and is set up to return -EINTR to userspace.
• The signal handler is executed.
• If the process is still running, it gets the return value from the system call, and it can make the same call again.

Returning early from the system call enables the user space code to immediately alter its behaviour in response to the signal. For example, terminating cleanly in reaction to SIGINT or SIGTERM.

On the other hand, some system calls are not allowed to be interrupted in this way. If the system calls stalls for some reason, the process can indefinitely remains in this unkillable state.

LWN ran a nice article that touched this topic in July.

To answer the original question:

• How to prevent this from happening: figure out which driver is causing you trouble, and either stop using, or become a kernel hacker and fix it.

• How to kill an uninterruptible process without rebooting: somehow make the system call terminate. Frequently the most effective manner to do this without hitting the power switch is to pull the power cord. You can also become a kernel hacker and make the driver use TASK_KILLABLE, as explained in the LWN article.