Unit 8: Process Management

I. Orientation: Processes in a Unix/Linux System

A process is a program in execution — the fundamental unit of work the operating system schedules and controls. The kernel creates a process whenever a program is loaded into memory and given CPU time, tracking each one through a data structure (the process control block) and a hierarchy rooted at the first process, init/systemd (PID 1). Process management is the set of commands and signals used to observe, prioritise, suspend, resume and terminate these processes.

Defining properties this unit relies on:

• State: every process is in one of a fixed set of states — running (R), sleeping/interruptible (S), uninterruptible sleep (D), stopped (T), or zombie (Z) after exit but before the parent reaps it.
• Ownership: each process has a real and effective UID/GID, so permission to signal a process depends on the user.
• Hierarchy: every process has a parent (PPID); killing a parent can orphan children, which are re-parented to PID 1.
• Foreground vs background: a shell runs one job in the foreground (holding the terminal) while others run in the background, detached from keyboard input.
• Signals: the kernel controls processes by delivering numbered signals (e.g. SIGTERM 15, SIGKILL 9, SIGSTOP 19, SIGCONT 18).

II. Concept of Processes — Program Execution as a Managed Entity

A. Definition and life cycle

A process is an instance of a running program together with its execution context (memory, registers, open files, environment).

• Creation: a parent calls fork() to duplicate itself, then exec() to replace its image with a new program: bash → fork → exec("/bin/ls").
• Address space: each process gets its own virtual memory — text (code), data, heap and stack segments — isolated from others.
• Termination: a process ends via exit() or an unhandled signal; its exit status is returned to the parent through wait().
• Zombie state: a terminated child whose status has not yet been collected shows as Z; it holds only a PID entry until reaped.

B. Foreground and background execution

Processes differ by their relationship to the controlling terminal.

1. Foreground: occupies the terminal and receives keyboard input; the shell waits for it to finish — sleep 30 blocks the prompt.
2. Background: launched with a trailing &, runs concurrently while the prompt returns — sleep 30 & prints [1] 4521 (job number and PID).

C. Significance

• Multitasking: the scheduler time-slices the CPU so many processes appear to run at once.
• Isolation: memory separation prevents one process corrupting another, improving stability and security.

III. Process ID (PID) — Identifying Every Process

A. Definition and allocation

The PID is a unique positive integer the kernel assigns to each process at creation.

• Uniqueness: no two live processes share a PID; numbers are reused only after a process exits.
• Key values: PID 1 is init/systemd; PID 0 is the kernel scheduler.
• PPID: the Parent Process ID links a process to its creator, forming the process tree viewable with pstree.
• Discovery: echo $$ prints the current shell's PID; pgrep firefox prints PIDs matching a name.

B. Why the PID matters

• Addressing target: every management command (kill, renice) needs a PID to act on a specific process — kill 4521.
• Files under /proc: the kernel exposes each process at /proc/<PID>/, e.g. /proc/4521/status lists its state, memory and UID.

IV. ps — Snapshot of Current Processes

A. Purpose and principle

ps prints a one-time static listing of processes at the moment it runs, unlike the live view of top.

• BSD syntax: ps aux — a (all users' processes), u (user-oriented format), x (include processes with no terminal).
• Standard syntax: ps -ef — -e (every process), -f (full format showing PPID and command).
• Columns: typical output shows USER PID %CPU %MEM VSZ RSS STAT START TIME COMMAND.

B. Common usage

• Filtering: ps aux | grep nginx isolates a named service.
• Custom fields: ps -eo pid,ppid,stat,comm prints only chosen columns.
• Tree view: ps -ejH or ps axjf shows the parent-child hierarchy indented.

$ ps -ef | head -2
UID   PID  PPID  C STIME TTY      TIME     CMD
root    1     0  0 09:12 ?        00:00:03 /sbin/init

V. top — Real-Time Process Monitor

A. Purpose and principle

top displays a continuously updating, interactive view of running processes ranked by resource use, refreshing every few seconds (default ~3 s).

• Header summary: shows uptime, load averages (1/5/15 min), task counts by state, CPU percentages (us user, sy system, id idle, wa I/O wait) and memory usage.
• Process rows: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND, where PR is priority and NI the nice value.

B. Interactive keys

• Sorting: P sorts by CPU, M by memory usage.
• Signalling: k prompts for a PID and signal to send; r renices a process.
• Filtering: u limits the display to one user; q quits.

C. Related tool

• htop: a colourised, scrollable alternative allowing mouse selection and per-core meters — not always installed by default.

VI. jobs — Listing Shell Jobs

A. Purpose and principle

jobs lists the processes started from the current shell that are running in the background or stopped, each tagged with a job number in brackets.

• Job number vs PID: [1] is a shell-local job spec, distinct from the system-wide PID; commands like fg and bg accept %1.
• Status markers: Running, Stopped, plus + (current job, default target) and - (previous job).

B. Usage

• List with PIDs: jobs -l adds each job's PID alongside its number.
• Reference forms: %1 (job 1), %+ or %% (current), %- (previous), %string (job whose command starts with string).

$ sleep 100 &
[1] 5233
$ jobs
[1]+  Running    sleep 100 &

VII. bg — Resuming a Job in the Background

A. Purpose and principle

bg resumes a suspended job and continues its execution in the background, freeing the terminal.

• Workflow: press Ctrl+Z to stop a foreground job (sends SIGSTOP), then bg %1 restarts it detached.
• Effect: equivalent to having launched the command with &, but applied after the fact.

B. Usage notes

• Default target: bg with no argument acts on the current job (+).
• Limitation: a backgrounded job needing terminal input will stop again until brought to the foreground.

VIII. fg — Bringing a Job to the Foreground

A. Purpose and principle

fg moves a background or stopped job back into the foreground, reattaching it to the terminal so it again receives keyboard input and blocks the prompt.

• Selection: fg %2 targets job 2; fg alone targets the current job.
• Pairing with bg: the two are complementary — bg detaches, fg re-attaches, and Ctrl+Z suspends between them.

B. Typical cycle

1. Suspend: Ctrl+Z on a running editor → [1]+ Stopped vim.
2. Resume in foreground: fg %1 returns control to the editor.

IX. kill — Sending Signals by PID

A. Purpose and principle

kill sends a signal to a process identified by PID; despite its name, it delivers any signal, not only termination.

• Default signal: kill 5233 sends SIGTERM (15), asking the process to shut down cleanly so it can save state.
• Forced kill: kill -9 5233 or kill -SIGKILL 5233 cannot be caught or ignored and terminates immediately — a last resort.
• List signals: kill -l prints all signal names and numbers.

B. Signal choices and job specs

• Common signals: SIGTERM (15, graceful), SIGKILL (9, forced), SIGHUP (1, reload config), SIGSTOP/SIGCONT (pause/continue).
• Job spec form: kill %1 signals a shell job by its job number rather than PID.

$ kill -15 5233     # polite request to stop
$ kill -9 5233      # force if it ignores SIGTERM

X. pkill — Signalling Processes by Name and Attribute

A. Purpose and principle

pkill signals processes matched by name or other attributes, so no PID lookup is needed — a pattern-based counterpart to kill.

• By name: pkill firefox sends SIGTERM to every process whose name matches.
• Signal selection: pkill -9 firefox forces termination of all matches.

B. Matching options and cautions

• Attribute filters: -u user restricts to a user's processes, -t pts/1 to a terminal, -f matches against the full command line.
• Companion pgrep: run pgrep -l firefox first to preview which PIDs will be hit.
• Risk: a broad pattern can signal unintended processes — pkill ssh may kill the session daemon; scope the match before firing.

C. kill versus pkill

1. kill: precise, acts on explicit PIDs, safe when the exact target is known.
2. pkill: convenient for groups by name, but broad patterns risk collateral termination.