Is there a way to kill a process in 'Z' (zombie) or 'D' (uninterruptible sleep) state without reboo

https://access.redhat.com/solutions/2972

环境

• Red Hat Enterprise Linux 4
• Red Hat Enterprise Linux 5
• Red Hat Enterprise Linux 6

问题

• Is there a way to kill a process in 'Z' (zombie) or 'D' (uninterruptible sleep) state without rebooting the system?

决议

Processes may exist in a number of states. These are reported by commands such as top and ps and indicate whether the process is running ('R'), sleeping ('S'), stopped ('T'), or in one of two special system states: zombie ('Z') and uninterruptible sleep ('D'). The zombie state is used during process termination - when a thread enters this state it is no longer running and only minimal context information is retained by the kernel.

Processes in either 'R' or 'S' state will respond to signals such as SIGTERM or SIGKILL, normally resulting in process termination. Processes in either the 'Z' or 'D' state will not respond to signals: in the case of processes in uninterruptible sleep, any signals sent while the task is blocked will be delivered to the process as soon as it returns to either the 'R' or the 'S' state (normally once IO or other kernel activity is complete).

For further information on process states and runtime properties refer to the documentation for the procfs virtual file system in man 8 proc.

The first process ID (PID 1) is always assigned to the init process. This is the process responsible (directly or indirectly) for starting all other processes on the system and manages changes to system run states (for example rebooting or shutting down the system). One of the supervisory roles played by the init process is the monitoring and cleaning up of orphaned zombie processes in the system:

• Whenever a process exits, the kernel retains part of the process's context (the task_struct) in order to be able to report exit status and statistics information back to the creator of the process. Processes that are in this state are conventionally referred to as zombie processes and are indicated by the state identifier 'Z'. Programs that create new processes can use the wait(2) family of system calls in order to retrieve this state information.

• In the case that a process exits before one or more of its children the child tasks become orphaned. In this situation the task_struct would be retained indefinitely, consuming kernel memory resources, and potentially limiting the number of additional processes (or threads) that can be started on the system.

• To prevent this leading to resource problems and starvation these processes are 'adopted' by the init task. The init task periodically checks for the existence of these orphans and calls wait(2) in order to clean them up. Once this takes place the kernel is able to discard the process state information and free the memory that it was consuming.

• If you see zombie processes with a parent different than init (can be inspected with ps -o <pid> command) persisting for a long time, it may be you encountered a bug. Contact the vendor who provided you with problematic program. Otherwise zombie processes should be cleaned up by init.

This is distinct from processes that are in 'D' state, or 'uninterruptible sleep'. This process state is used to suspend a process while operations that would prevent it continuing take place. This includes IO operations and other kernel operations that modify the process's address space or memory content (for instance allocating memory or retrieving data from disk during a page fault). These processes cannot be safely interrupted and will remain in this state until the operation either completes successfully or fails with an error.

If operations do not complete due to a hardware or software fault (for example network connectivity problems) it may not be possible to eliminate all processes in 'D' state without rebooting.

If large numbers of processes are in 'Z' or 'D' state, or if processes are remaining in 'Z' or 'D' states for excessive periods of time, this may indicate a functional or capacity problem with the system. Further analysis by Red Hat Global Support Services may be required to determine the root cause for such behaviour

 

相关的参考文章：https://blog.csdn.net/msdnchina/article/details/89218584