How to Kill Zombie Processes on Linux – How-To Geek

Fatmawati Achmad Zaenuri/Shutterstock

Programs that are poorly written or performing badly can leave zombie processes lurking inside your Linux computer. Find out how zombies are created, and how you can finally lay them to rest.

Linux, of course, has to keep track of all the applications and daemons running on your computer. One of the ways it does this is by maintaining theprocess table. This is a list of structures in kernel memory. Each process has an entry in this list that contains some information about it.

There isnt a great deal in each of the process table structures. They hold the process ID, a few other data items, and a pointer to theprocess control block(PCB) for that process.

Its the PCB that holds the many details Linux needs to look up or set for each process. The PCB is also updated as a process is created, given processing time, and finally destroyed.

The Linux PCB contains over 95 fields. Its defined as a structure called task_struct.h, and its over 700 lines long. The PCB contains the following types of information:

The Process State can be any of the following:

In the Zombie state, the parent process calls one of the wait() families of functionswhen the child process is created. It then waits for a state change in the child process. Has the child process been stopped, continued, or killed by a signal? Has it terminated by running through the natural completion of its code?

If the state change is one that means the child process has stopped running, its exit code is read. Then, the childs PCB is destroyed and its entry in the process table is removed. Ideally, this all happens in the blink of an eye, and processes in the zombie state dont exist for very long.

RELATED: How to Run and Control Background Processes on Linux

A poorly written parent process might not call the wait() function when the child process is created. This means nothing is watching for state changes in the child process, and the SIGCHLD signal will be ignored. Or, perhaps another application is affecting the execution of the parent process, either due to poor programming or malicious intent.

However, if the parent process isnt watching for state changes in the child process, the proper system housekeeping wont occur. The PCB and the entry in the process table wont be removed when the child process terminates. This results in the zombie state never being removed from the PCB.

Zombies do use a bit of memory, but they dont usually pose a problem. The entry in the process table is small, but, until its released, the process ID cant be reused. On a 64-bit operating system, thats unlikely to cause any issues because the PCB is much larger than the process table entry.

A huge number of zombies could, conceivably, affect the amount of memory thats free for other processes. If youve got that many zombies, though, youve got a serious problem with the parent application or an operating system bug.

You cant kill a zombie process because its already dead. It wont respond to any signals because its been removed from memorytheres nowhere to send a SIGKILL signal. You can try sending the SIGCHLD signal to the parent process, but if it didnt work when the child process terminated, its unlikely to work now, either.

The only reliable solution is to kill the parent process. When its terminated, its child processes are inherited by the init process, which is the first process to run in a Linux system (its process ID is 1).

The init process regularly performs the necessary cleanup of zombies, so to kill them, you just have to kill the process that created them. The top command is a convenient way to see if you have any zombies.

Type the following:

This system has eight zombie processes. We can list theseby using the ps command and piping it into egrep. Again, zombie processes have a state flag of Z, and youll usually also see defunct.

Type the following:

The zombie processes are listed.

This is a neater way to discover the process IDs of zombies than scrolling back and forth through top. We also see that an application called badprg spawned these zombies.

The process ID of the first zombie is 7641, but we need to find the process ID of its parent process. We can do so by usingpsagain. Well use theoutput option (-o) to tell ps to display only the parents process ID, and then pass it with the ppid= flag.

The process we want to find will be indicated by using the -p (process) option, and then passing in the zombies process ID.

Therefore, we type the following command to look up the process information for process 7641, but it will only report the ID of the parent process:

Were told the parent process ID is 7636. We can now cross-reference this by usingps once more.

We see this matches the name of the parent process from earlier. To kill the parent process, use the SIGKILL option with the kill command as follows:

Depending on the owner of the parent process, you might also need to use sudo.

unless theyre in a massive horde. A few arent anything to worry about and a simple reboot will wipe them out.

However, if you notice that an application or process is always spawning zombies, thats something you should look into. Its most likely just a sloppily written program, in which case, perhaps theres an updated version that properly cleans up after its child processes.

See more here:
How to Kill Zombie Processes on Linux - How-To Geek