Linux with Operating System Concepts

core dump
is an image or copy of the process’ memory at the time the termina-
tion occurred. The core dump is produced to help a programmer debug the program. The 
core dump however can be a large file. As a user, if you write programs that terminate 
abnormally, you might find core dumps in your file space. Given a core dump, you can 
view its contents through a debugger program (we will not cover that in this text as this 
text does not concentrate on Linux programming). Note: as core dumps can be large, 
unless you plan on using them for debugging, you should delete them as they occur.
When a process does terminate, if it has spawned any children, this creates orphans. An 
orphan
is a process whose parent has died. This creates a problem because, in many cases, 
a process reports back to its parent. Without a parent, the process cannot report. Therefore, 
upon a parent process terminating, the child process is re-parented, or adopted, by the init 
process.
The child process could be orphaned because of a number of different situations. 
First, the parent process may unexpectedly terminate (crash) because of some errone-
ous situation. Second, a child process may be launched to run in the background as 
a long-running job. In such a situation, it is not necessarily expected that the parent 
would run for the same duration. In this case, the parent is expected to terminate at 
some point while the child, which is now somewhat detached from the parent in that it 
is running independently, continues to exist. The third situation arises when the parent 
process creates the child process using the exec function call, in which case the parent 
dies and the child takes over for the parent, inheriting its PID. In this case, the child 
does not require re-parenting because the parent’s parent automatically is inherited as 
the child’s parent.
Another situation may arise in which a process has terminated, whether normally or 
abnormally, but remains in the system. In this case, the process is referred to as a 
zombie
. 
In essence, such a process retains its PID but no longer receives attention from the pro-
cessor. You can find zombie processes when you issue the ps command. Zombie process 
names will appear in ps with a STAT (state) of “Z.”
The reason that zombies can arise is that some processes persist until their parent “cleans 
up after them.” If the parent process is currently suspended or sleeping, a terminating pro-
cess must wait for the parent to clean up. This clean up might simply be to report back its 
exit status or it may involve using data from the child. The parent itself might have placed 
itself into a waiting situation. If this is the case, the parent may resume only if a particular 
event arises or a specified amount of time has elapsed. For instance, the parent might issue 
a 24 hours wait and its child might terminate within an hour. The child would persist in 
the operating system for at least another 23 hours.
Even though zombies do not take up system resources, they can be annoying as they 
continue to appear in ps listings. Unlike normal processes which the user can kill (see 
below), the zombie process cannot be killed until the parent resumes. Therefore, if you find 

---

Managing Processes
◾
149
a lot of zombie processes and you want to get rid of them, restart the parent process(es) 
of the zombies.
This leads us to the discussion of killing processes. Why would you want to kill a process 
and how does this differ from exiting a process? In some cases, killing a process is the same 
as exiting a process. This is especially true if the process does not currently have any open 
resources.
Consider, for instance, using a text editor (e.g., vi or emacs). You can exit the program 
normally, which makes sure that any open files are first closed properly. If the program 
does not have an open file, then exiting the program and killing it leave the system in 
the same state. However, if you do have an open file and you kill the process, the file may 
become corrupted and so the system would be in a different state than had you exited the 
program properly.
Why then would you kill a process? Primarily, you kill processes that are not respond-
ing. This happens often in the Windows operating system but is less common in Linux. 
However, it still happens. In addition, a process launched into the background has no inter-
face with the user and so could be stopped by killing it. Finally, if an emergency situation 
has arisen requiring that the system be shut down quickly, you or the system administrator 
may have no choice but to kill all running processes.
4.6.2 Methods of Killing Processes
To kill a process, the command is naturally 
kill
. You must specify the PID of the pro-
cess to kill. You can specify multiple PIDs in one kill command. You must however be the 
owner of the process(es) specified or root to kill it off. The kill command also accepts an 
interrupt signal. The signal indicates what action the application should take upon receiv-
ing the signal. The signal can specify that the software should try to recover from an error 
or that that the process should terminate immediately. There are nine signals available for 
the kill command, as shown in Table 4.3, although in fact there are 64 total signals avail-
able for programs in Linux.
Signal number 1 is also known as SIGHUP (signal hangup). This signal is used to 
terminate communication if a signal is lost. This can prevent a process from waiting 
indefinitely for a response via telecommunications. In the cases of signal numbers 2–8, 
TABLE 4.3 
Kill Signals