You are on page 1of 6

Chapter07.

Monitoring and Managing Linux Processes

Processes
What is a process
A process is a running instance of a launched, executable program. In other meaning, an instance of a
computer program that is being executable.

A process consists of:


• an address space of allocated memory.
• security properties including ownership credentials and privileges.
• one or more execution threads of program code.
• the process state.
The environment of a process includes
• local and global variables.
• a current scheduling context.
• allocated system resources, such a s file descriptors and network ports.

Signals
The operating system communicates to process through Signal. These signals report events or errors
situations to processes.in many cases, these signals will result in the process exiting. The typical signals are
SIGTERM, which terminates the process, it asks to exit cleanly. Another is SIGKILLS, which kills the process,
process is required exit immediately.
An existing (parent) process duplicates its own address space (fork) to create a new(child) process structure.
Every new process is assigned a unique process ID (PID) for tracking and security. The PID and the parent's
process-ID (PPID) are elements of the new process environment. Any process may create a child process.
All processes are descendants of the first system process, which is systemd on a RHEL7 system.
# ps –ef | grep systemd
root 1 0 1 20:54 ? 00:00:01 /usr/lib/systemd/systemd

Processes properties
The basic command to see the list of running processes is ps (process status).
Run it in your terminal and you should see something like this:
# ps
PID TTY TIME CMD
27267 ttys002 0:06.82 vim
We can pass a -o parameter to format the output with the information that we want. Let’s run it again
asking for all the metadata we want to talk about:
# ps -o pid,ppid,tty,uid,args
PID PPID TTY UID ARGS
28838 28836 ttys000 1935087709 -zsh
27267 13833 ttys002 1935087709 vim

PID: Every process has an id associated to it. It’s a unique identifier, and that’s how we can reference a
specific process.
PPID: That’s the parent’s PID. Every (well, almost) process has a parent process, the process that was
responsible for its creation.
TTY: TeleTypewriter(tty), This is an identifier of the terminal session that triggered this process. That’s called
the controlling terminal. Almost every process will be attached to a terminal (except for daemons).In top
example you can see that I have two terminal sessions running (ttys000 and ttys0002).
check your current tty with the, surprise, tty command:
# tty
/dev/ttys000
TeleTypewriter(tty), Pseudo-Terminal slave(pts)
UID: This is the user id. It’s the identifier for the user that’s the owner of this process, and that’s what will
define the permissions this process will have.
You can check your user id with the command id:
# id -u John
1935087709
ARGS: The command (followed by its arguments) that’s running in this process.
There are many more properties related to a process, like the CPU/memory usage percentage, the start
time and so on. You can check the entire list in the ps man page:
# man ps

How processes are born


Processes creation is achieved in 2 steps in a UNIX system: the fork and the exec.
Every process is created by using the fork system, call. system calls mean, program send a message to the
kernel (in this case, asking for the creation of a new process).
What fork does, is create a copy of the calling process. The newly created process is called the child, and
the caller is the parent. This child process inherits everything that the parent has in memory, it’s an almost
exact copy (pid and ppid are different, for instance).
One thing to be aware of is that if a process is using 200MB of memory, when it forks a child, the newly
created process will use more 200MB. This can easily become an accidental “fork bomb”, that will consume
all the available resources of the machine.
The second step is the exec. What exec does is replace the current process with a new one. The caller
process is gone forever, and the new process takes its place. If you try to run this command in a terminal
session:
# exec vim
vim will be opened normally, as it was a direct call to it, but as soon as you close it, you will see that the
terminal is gone as well. So here’s what happened:
You had a shell process running (bash, zsh or similar). In the moment that you called exec, passing vim and
a parameter, it replaced the bash process with a vim process, so when you close vim, there is no shell there
anymore.
You will see this fork + exec pattern all over the place in a UNIX system. If you are running a bash process,
when you call, say, ls, to list your files, what actually is done is exactly this. The bash process calls fork to
create an exact copy of itself, then call exec, to replace this copy with the ls process. When the ls process
exits, you are back to the parent process, that is bash. And talking about a process exiting…

Controlling Jobs
Jobs and sessions
Job control is a command shell feature allowing a single shell instance to run and manage multiple
commands. Without job control, a parent shell forks a child process to run a command, sleeping until the
child process exits. When the shell prompt redisplays, the parent shell has returned. With job control,
commands can be selectively suspended, resumed, and run a synchronously, allowing the shell to return
for additional commands while child processes run.
# Ps –aux
User:
Pid: process identifier
%cpu: The percentage of time the process has used the CPU since the process started
%mem: The percentage of real memory used by this process.
Vsz: Virtual Memory Size. It includes all memory that the process can access, including memory that is
swapped out, memory that is allocated, but not used, and memory that is from shared libraries.
Rss: Resident Set Size and is used to show how much memory is allocated to that process and is in RAM.
Tty:
Stat: Contains the state of the process
Start: The starting time of the process
Time: The total execution time for the process
Command:
A foreground process is a command running in a terminal window. The terminal's device ID (tty) is the
process's controlling terminal.
Foreground processes receive keyboard-generated input and signals and are all owed to read from or
write to the terminal (e.g., via stdin and stdout). A process session is created when a terminal or console
first opens (e.g., at login or by invoking new Terminal in stance). All processes (e.g., the first command shell,
its children, and pipelines) initiated from that terminal share the same session ID. Within a session, only one
process can be in the foreground at a time.

Background process is started without a controlling terminal because it has no need for terminal interaction.
In a ps listing, such processes (e.g., service daemons and kernel process threads) display a question mark
(?) in the TTY column. Background processes which(improperly) attempt to read from or write to the
terminal may be suspended.

Running jobs in the background


Any command can be started in the background by appending an ampersand (&) to the command line.
The bash shell displays a job number (unique to the session) and the PID of the new child process.
List All Processes in Current Shell.
# sleep 10000 &
[1] 5974
#
The bash command shell tracks jobs, per session, in a table displayed with the jobs command.
# jobs
[+1] Running Firefox &
#
The ps option j displays job in formation, including the initial command shell of each session.
# ps j
To restart the process in the background, use the bg command with the same job ID.
# bg %1
[1]+ sleep 100000 &

Background jobs can reconnect to the controlling terminal by being brought to the foreground using the
fg command with the job ID (%job number).
Killing Processes
Process control using signals
A signal is a software interrupt delivered to a process. Signals report events to an executing program. Events
that generate a signal can be an error, external event (e.g., 1/0 request or expired timer), or by explicit
request (e.g., use of a signal-sending command or by key board sequence).
The following table lists the fundamental signals used by system administrators for routine process
management. Refer to signals by either their short (HUP) or proper (SIGHUP) name
9 KILL Kill, unblockable
15 TERM Terminate(default)
Each signal has a default action, usually one of the following:
Term - Cause a program to terminate(exit) at once.
Core - Cause a program to save a memory image (core dump), then terminate.
Stop - Cause a program to stop executing (suspend) and wait to continue (resume).

Commands for sending signals by explicit request


Users signal their current foreground process by typing a keyboard control sequence to suspend (Ctrl-z),
kill (Ctrl-c) , or core dump (Ctrl - \) the process. To signal a background process or processes in a different
session requires a signal - sending command.

The kill command sends a signal to a process by ID. Despite its name, the kill command can be used for
sending any signal, not just those for terminating programs.
# kill pid
# kill –signal pid
# kill –l
Use killall to send a signal to one or more processes matching selection criteria, such as a command name,
processes owned by a specific user, or all system-wide processes.
# killall command-parttern
# killall –signal command-pattern
# killall signal –u username command-pattern

The pkill command, like killall, can signal multiple processes. pkill uses advanced selection criteria, which can
include combinations of:
Command - Processes with a pattern - matched command name.
UID - Processes owned by a Linux user account, effective or real.
GID - Processes owned by a Linux group account, effective or real.
Parent - Child processes of a specific parent process.
Terminal - Processes running on a specific controlling terminal.
# pkill command-pattern
# pkill –signal comman-pattern
# pkill –G GID command-pattern
# pkill –P PPID command-pattern
# pkill –t terminal_name –U UID command-pattern

Monitoring Process Activity


Real-time process monitoring
The top program is a dynamic view of the system's processes, displaying a summary header followed by a
process or thread list similar to ps information.
Unlike the static ps output, top continuously refreshes at a configurable interval, and provides capabilities
for column re ordering, sorting, and highlighting.
# top
Default output columns are recognizable from other resource tools:
• The process ID (PID).
• Username (USER) is the process owner.
• Virtual memory (VIRT) is all memory the process is using, including the resident set, shared libraries, and
any mapped or swapped memory pages. (Labeled vsz in the ps command.)
• Resident memory (RES) is the physical memory used by the process, including any resident shared objects.
(Labeled RSS in the ps command.)
• Process state (S) displays as:
• D = Uninterruptable Sleeping
• R = Running or Runnable
• S = Sleeping
• T = Stopped or Traced
• z = Zombie
• CPU time (TIME) is the total processing time since the process started. May be toggled to include
cumulative time of all previous children.