Poorly written or malfunctioning programs can leave zombie processes lurking inside your Linux computer. Find out how zombies are created and how in short you can let them rest.
How procedural states work in Linux
Linux, of course, you have 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 procedure 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 procedural control block (PCB) for that procedure.
It is the PCB that contains the many details that Linux needs to find or configure for each procedure.. The PCB also updates as a procedure is created, it is given processing time and in short it is destroyed.
The Linux PCB contains more than 95 fields. It is defined as a structure called task_struct.hand has more than 700 lines. The PCB contains the following types of information:
- State of procedure: The states are described below.
- Procedure number: Your unique identifier within the operating system.
- Program counter: When this procedure has access to the CPU, the system will use this address to find the next instruction of the procedure to be executed.
- Records: The list of CPU registers used by this procedure. List can contain accumulators, index registers and stack pointers.
- Open file list: Files associated with this procedure.
- CPU programming information: Used to set the frequency and duration of the CPU processing time to this procedure. The priority of the procedure, scheduling queue indicators and other scheduling parameters should be recorded on the PCB.
- Memory management information: Details about the memory used by this procedure, such as the memory start and end addresses of the procedure and pointers to memory pages.
- E / S: Any input or output device used by the procedure.
The “Status of the procedure” can be any of the following:
- R: A running or executable procedure. Running means it is receiving CPU cycles and running. An executable procedure is ready to run and waiting for a CPU slot.
- S: A sleeping procedure. The procedure is waiting for an action to complete, as an input or output operation, or that a resource is available.
- D: The procedure 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 state of “suspension”, a procedure in this state will not respond to signals until the system call is complete and execution has returned to the procedure.
- T: The procedure is over (stopped) because he received the
SIGSTOPsign. That will only answer alSIGKILLOSIGCONTsigns, that kill the procedure or instruct you to continue, respectively. This is what happens when you change foreground (fg) for background (bg)Chores. - WITH: A zombie procedure. When a procedure is completed, it doesn't just go away. Frees whatever memory you are using and removes itself from memory, but its entry in the process table and PCB remains. Its status is set to
EXIT_ZOMBIE, and its parent procedure is notified (for himSIGCHLDsign) that the child procedure has finished.
In the zombie state, the parent procedure calls one of the wait() function families when child procedure is created. Then wait for a state change in the child procedure. Has the child's procedure been stopped, continued or eliminated by a signal? Have you finished running natural completion of your code?
If the state change is one that means that the child procedure has stopped executing, your exit code is read. After, the child's PCB is destroyed and its entry in the procedure table is removed. Ideally, all 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 procedure might not call the wait() function when child procedure is created. This means that nothing is pending of the state changes in the child procedure, and the SIGCHLD the signal will be ignored. Or maybe another application is affecting the execution of the main procedure, either due to bad programming or malicious intent.
Despite this, if the parent procedure is not aware of state changes in the child procedure, proper system maintenance will not occur. PCB and process table entry will not be removed when child procedure ends. This results in the zombie state never being removed from the PCB..
Zombies use a little memory, but in general they do not represent an obstacle. The entry in the process table is small, but, until it is published, procedure id cannot be reused. On an operating system of 64 bits, this is unlikely to cause problems because the PCB is much larger than the process table entry.
A lot of zombies could, possibly, affect the amount of memory that is free for other processes. Despite this, if you have so many zombies, you have a serious obstacle with the main application or an operating system error.
How to remove Zombie processes
You cannot kill a zombie procedure because it is already dead. 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 parent procedure, but if it didn't work when the child procedure finished, unlikely to work now either.
The only reliable solution is to remove the main procedure. When it ends, its child processes are inherited by the init process, which is the first procedure to run on a Linux system (your procedure id is 1).
the init The procedure regularly performs the necessary cleaning of zombies, so to kill them, you just have to kill the procedure that created them. the top The command is a convenient way to see if you have zombies.
Write the following:
top
This system has eight zombie processes. Us you can list these using the ps command and channeling it into egrep. One more time, zombie processes have a status flag of “WITH” and, in general, you will also see “extinct”.
Write the following:
ps to | egrep "WITH|defunct"
Zombie processes are listed.
This is a neater way of figuring out zombie procedural IDs than scrolling back and forth top. We also see that an application called “badprg” spawned these zombies.
The procedure ID of the first zombie is 7641, but we need to find the procedure id of its parent procedure. We can do it using ps-o) tell ps to show only the parent's procedure ID and then pass it with the ppid= flag.
The procedure that we want to find will be indicated through the -p (process) and then pass the procedure id of the zombie.
Because, we write the following command to find the procedure information for the procedure 7641, but it will only report the ID of the main procedure:
ps -o ppid = -p 7641
It was mentioned to us that the ID of the main procedure is 7636. Now we can cross-reference using ps one more time.
We see that this matches the name of the main procedure above. To kill the main procedure, use the SIGKILL option with the kill command as follows:
kill -SIGKILL 7636
Depending on the owner of the main procedure, it is possible that you should also use sudo.
Zombies are not scary …
… Unless they are in a massive horde. Some are nothing to worry about and a simple reboot will remove them.
Despite this, if you notice that an application or a procedure always spawns zombies, that's something you need to analyze. 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.
