What is a Process?

A process can be defined as a representation of a running program. It is also kn

own as a task. A process allows us to manage a program's resources such as use
of CPU time, memory, state, name, owner, and more. The kernel assigns an identi
fication number to each process called a process ID or PID.
A process can be an application, a command, an executable file or binary file.
Unix-like operating systems can run multiple processes at once with no interfere
nce with each other. A single program can spawn multiple processes simultaneou
sly. Each instance can be a separate process.
The kernel records information about each process. This information includes th
e current status of the process, owner of the process, the resources that the pr
ocess has consumed, the execution priority of the process, CPU usage, and more.
We are going to focus on those process attributes that are of interest for the
Linux Administrator.
USER/UID
This is user who created the process and owns it.
PID
This is the process identification number. The kernel assigns it to each process
.
PPID
This is the parent process ID number. When a process spawns other processes, the
original process is the parent, and the spawned processes are the children. The
PPID of a process is the PID of the parent from which it was spawned.
This is a good component when trying to figure out whether an unknown process is
legit or if it is that your box has been hacked.
C
This is the processor utilization over the lifetime of the process.
START
This is the date when the process started.
STIME
System time when the process started.
TTY
This is the terminal attached to the process or the control terminal for a proce
ss. That is, this is the terminal from which the process was started. A question
mark in this column means that the process does not longer have a controlling t
erminal.
TIME
This is the amount of time the process has spent on the CPU or the cumulative CP
U time required to run the process.
%CPU
Percentage of the CPU the process has consumed. For a system that has more than
one processor, this column will add up to more than 100%.
%MEM
Percentage of real memory the process has consumed.
VSZ
The amount of virtual memory the process has taken.
RSS
The amount of actual or physical memory (number of pages in memory) the process
has taken.

CMD/COMMAND
This is the name of the process and its command-line parameters.
F
This is a system flag assigned to the process by the kernel.
S/STAT
This is the state of the process. These are the possible states:
S = the process is sleeping. This happens when any process that is ready to run
has to wait for an even or a signal.
O = the process is running on the processor.
R = the process is running (it is actually on the CPU).
T = the process stopped or it is being traced by a debugger.
Z = zombie. This means that the process has terminated by (1) the parent process
was
improperly terminated and until it terminates, the init process cannot kill the
child process
or (2) the parent process has not acknowledged that its child process is termina
ted.
D = Asleep and not interruptible sleep.
W = The process is swapped out (no resident pages in memory.
< = This is a high-priority process (higher than normal).
N = The process is running at low priority.
L = Pages in memory are locked there.
s = The process is a session leader (It is the main process in a session).
1 = The process is a multi-threaded process.
+ = The process is running in the foreground.

PRI
The priority of the process. The higher the number, the lower the priority.
NI
The nice value of the process. This value determines the priority of a process.
ADDR
The memory address of the process.
SZ
Approximate amount of swap space needed if the process was swapped out.
WCHAN
Address of the kernel function where the process is sleeping.

Programs can modify their status information.

--------------------------------------------------------------------------------
----------------------------------------------------------------------
The zombie process only contains the return value of the child, the parent shoul
d normally wait for that return value..
if it doesn't a zombie process will come up. (Application Bug)
--------------------------------------------------------------------------------
---------------------------------------------------------------------------
Zombies are dead processes. You cannot kill the dead. All processes eventually
die, and when they do they become zombies. They consume almost no resources, w
hich is to be expected because they are dead! The reason for zombies is so the
zombie's parent (process) can retrieve the zombie's exit status and resource usa
ge statistics. The parent signals the operating system that it no longer needs
the zombie by using one of the wait() system calls.
When a process dies, its child processes all become children of process number 1
, which is the init process. Init is ``always'' waiting for children to die, so
that they don't remain as zombies.
If you have zombie processes it means those zombies have not been waited for by
their parent (look at PPID displayed by ps -l). You have three choices: Fix the
parent process (make it wait); kill the parent; or live with it. Remember that
living with it is not so hard because zombies take up little more than one extr
a line in the output of ps.
--------------------------------------------------------------------------------
----------------------------------------------------------------------------
One of the early things people learn about Unix is that a "kill -9" is invincibl
e- that a process must die if you send it a KILL (-9). However, that's not entir
ely true:
A process can be sleeping in kernel code. Usually that's because of faulty hardw
are or a badly written driver- or maybe a little of both. A device that isn't se
t to the interrupt the driver thinks it is can cause this, for example- the driv
er is waiting for something its never going to get. The process doesn't ignore y
our signal- it just never gets it.

A zombie process doesn't react to signals because it's not really a process at a
ll- it's just what's left over after it died. What's supposed to happen is that
its parent process was to issue a "wait()" to collect the information about its
exit. If the parent doesn't (programming error or just bad programming), you get
a zombie. The zombie will go away if its parent dies- it will be "adopted" by i
nit which will do the wait()- so if you see one hanging about, check its parent;
if it is init, it will be gone soon, if not the only recourse is to kill the pa
rent..which you may or may not want to do.

Finally, a process that is being traced (by a debugger, for example) won't react
to the KILL either.