Programs that are poorly written or malfunctioning can leave zombie processes lurking inside your Linux computer. Find out how zombies are created and how you can finally put them to rest.
How process states work in Linux
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 keeping the process table. This is a list of structures in kernel memory. Each process has an entry in this list that contains information about it.
There is not much in each of the process table structures. They hold the process identification, some other data items, and a pointer to the process control block (PCB) for that process.
It is the PCB that contains the many details that Linux needs to find or configure for each process. The PCB is also updated as a process is created, given processing time, and eventually destroyed.
The Linux PCB contains more than 95 fields. It is defined as a structure called
task_struct.hand it has more than 700 lines. The PCB contains the following types of information:
- Process status: The states are described below.
- Process number: Your unique identifier within the operating system.
- Program counter: When this process has access to the CPU, the system will use this address to find the next instruction of the process to be executed.
- Records: The list of CPU registers used by this process. The list can contain accumulators, index registers, and stack pointers.
- Open file list: Files associated with this process.
- CPU programming information: Used to determine the frequency and duration of the CPU processing time to this process. The process priority, scheduling queue flags, and other scheduling parameters must be recorded on the PCB.
- Memory management information: Details about the memory used by this process, such as the process’s memory start and end addresses and pointers to memory pages.
- I / O status information: Any input or output device used by the process.
The “Process Status” can be any of the following:
- A: A running or executable process. Running means it is receiving CPU cycles and running. An executable process is ready to run and waiting for a CPU slot.
- S: A process of sleeping. The process is waiting for an action to complete, such as an input or output operation, or for a resource to be available.
- D: The process is in a state of uninterrupted suspension. You are using a blocking system call and cannot continue until the system calls have been completed. Unlike the “sleep” state, a process in this state will not respond to signals until the system call is complete and execution has returned to the process.
- T: The process has ended (stopped) because it received the
SIGSTOPsign. That will only answer toward
SIGCONTsignals, which kill the process or tell it to continue, respectively. This is what happens when you change foreground (
fg) for background (
- Z: A Zombie process. When a process is complete, it doesn’t just go away. It frees whatever memory it is using and removes itself from memory, but its PCB and process table entry remains. Its status is set to
EXIT_ZOMBIE, and its parent process is notified (by the
SIGCHLDsignal) that the child process has terminated.
In the Zombie state, the parent process calls one of the
wait() function families when the child process is created. Then wait for a state change in the child process. Has the child’s process been stopped, continued or eliminated by a signal? Have you ended up running the natural completion of your code?
If the state change is one that means that the child process has stopped running, its exit code is read. The child’s PCB is then destroyed and its entry in the process table is removed. Ideally, all of this happens in the blink of an eye, and processes in the zombie state don’t exist for long.
RELATED: How to run and control background processes in Linux
What Causes Zombie Processes in Linux?
A misspelled parent process might not call the
wait() function when the child process is created. This means that nothing is pending on the state changes in the child process, and the
SIGCHLD the signal will be ignored. Or maybe another application is affecting the execution of the main process, either due to bad programming or malicious intent.
However, if the parent process is not aware of state changes in the child process, proper system maintenance will not occur. The PCB and the process table entry will not be removed when the child process ends. This results in the zombie state never being removed from the PCB.
Zombies use a bit of memory, but they generally don’t pose a problem. The entry in the process table is small, but, until published, the process ID cannot be reused. On a 64-bit operating system, this is unlikely to cause problems because the PCB is much larger than the process table entry.
A large number of zombies could possibly affect the amount of memory that is free for other processes. However, if you have that many zombies, you have a serious problem with the main application or an operating system error.
How to kill Zombie processes
You cannot kill a zombie process because it is already dead. It will not respond to any signal because it has been removed from memory; there’s nowhere to send a
SIGKILL sign. You can try to send the
SIGCHLD signal to the parent process, but if it didn’t work when the child process ended, it’s unlikely it will work now either.
The only reliable solution is to kill the main process. When terminated, its child processes are inherited by the
init process, which is the first process to run on a Linux system (its process ID is 1).
init The process regularly performs the necessary cleaning of zombies, so to kill them, you just have to kill the process that created them. The
top The command is a convenient way to see if you have zombies.
Write the following:
This system has eight zombie processes. We you can list these using the
ps command and channeling it into
egrep. Again, zombie processes have a status flag of “Z” and you will usually see “extinct” as well.
Write the following:
ps aux | egrep "Z|defunct"
The zombie processes are listed.
This is a neater way of figuring out the zombies’ process IDs than scrolling back and forth
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 it using
again. We will use the output option (
ps to show only the parent’s process id and then pass it with the
The process that we want to find will be indicated by the
-p (process) and then pass the zombie’s process ID.
So we write the following command to look up the process information for process 7641, but it will only report the ID of the main process:
ps -o ppid= -p 7641
We were told that the main process ID is 7636. Now we can cross-reference using
ps one more time.
We see that this matches the name of the main process above. To kill the main process, use the SIGKILL option with the kill command as follows:
kill -SIGKILL 7636
Depending on the owner of the main process, you may also need to use
Zombies are not scary …
… Unless they are in a massive horde. Some are nothing to worry about and a simple reboot will remove them.
However, if you notice that an application or process always spawns zombies, that’s something you need to look into. Most likely it is just a sloppily written program, in which case maybe there is an updated version that cleans up properly after its child processes.