CH04 — PRESENTATION

Process Management

Understand how Linux manages running programs: inspect processes with ps and top, control CPU priority with nice and renice, send signals with kill, manage foreground and background jobs, and keep processes running after logout with nohup.

Slide 1 — What Is a Process?

A Running Instance of a Program

A process is a program in execution. When you run ls, the kernel creates a new process — allocates memory, assigns a Process ID (PID), loads the program code, and begins executing it. When ls finishes, the process exits and releases its resources.

Every process has a parent (PPID). The first process is systemd (PID 1) — it starts all other processes on the system. This creates a process tree: systemd spawns your shell, your shell spawns the commands you run, and so on.

Key process attributes: PID (unique identifier), PPID (parent PID), UID/GID (owner), state (running/sleeping/zombie), priority (nice value), memory usage (VSZ/RSS), and CPU time consumed.

Slide 2 — Process States
R
Running
Actively executing on CPU or in the run queue waiting for a CPU slot.
S
Sleeping
Interruptible sleep — waiting for an event (I/O, signal). Most processes spend most time here.
D
Uninterruptible
Waiting for I/O that cannot be interrupted. Too many D processes = I/O bottleneck or storage problem.
T
Stopped
Paused — received SIGSTOP or Ctrl+Z. Can be resumed with SIGCONT or the fg command.
Z
Zombie
Process has exited but its entry remains until parent reads its exit status. Cannot be killed — kill the parent.
I
Idle
Kernel thread in uninterruptible sleep for too long. Informational — not an error state.
Slide 3 — Viewing Processes: ps and top
# ps — process snapshot $ ps aux # All processes, detailed (BSD syntax) $ ps aux | grep nginx # Find specific process $ ps -ef # All processes with PPID (POSIX syntax) $ ps -eo pid,comm,nice,stat # Custom columns: PID, name, nice, state $ ps --forest # Show process tree (ASCII art) $ pgrep nginx # Get PID of process by name $ pstree # Visual process tree # Understanding ps aux output USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.1 225444 9116 ? Ss Jan15 0:02 /sbin/init www-data 1247 0.2 0.5 362144 41208 ? S 09:00 0:15 nginx: worker # top — real-time process monitor $ top # Interactive monitor (q to quit) $ top -u www-data # Show only www-data's processes $ htop # Enhanced top with colors (install separately) # top interactive commands # k = kill process by PID # r = renice (change priority) # P = sort by CPU usage # M = sort by memory usage # 1 = show per-CPU statistics
Slide 4 — CPU Priority: nice and renice

Controlling How Much CPU a Process Gets

The Linux scheduler uses "nice values" to determine relative CPU priority. The range is -20 (highest priority, most CPU) to +19 (lowest priority, least CPU). The default for new processes is 0.

Only root can set negative nice values (increase priority). Any user can make their own processes nicer (decrease priority). The name comes from "being nice" to other users by not hogging CPU.

-20Highest
Priority
-10Root
Only
0Default
Priority
+10Lower
Priority
+19Lowest
Priority
# nice — set priority when STARTING a process $ nice -n 10 backup.sh # Start backup at nice 10 (lower priority) $ nice -n 15 tar -czvf archive.tar.gz /home/ # Low-priority archive $ sudo nice -n -5 critical_task # High priority (root required for negative) # renice — change priority of RUNNING process $ renice -n 5 -p 1234 # Set PID 1234 to nice 5 $ sudo renice -n -10 -p 5678 # Increase priority (root required) $ renice -n 10 -u student # Nice all processes owned by student # Check nice values $ ps -eo pid,comm,nice | sort -k3 -n # List processes sorted by nice value $ top # NI column shows nice value for each process
Slide 5 — Sending Signals: kill and killall

Signals Are How Processes Communicate

Signals are software interrupts sent to processes to notify them of events or request actions. The kill command sends signals — despite its name, it can send any signal, not just termination signals.

SignalNumberNameDescription
SIGHUP1HangupReload config without restart. Used for daemons: kill -1 PID
SIGINT2InterruptCtrl+C — polite termination request. Process can catch and handle.
SIGTERM15TerminateDefault kill signal. Polite — allows cleanup. Process can catch.
SIGKILL9KillImmediate, forced termination. Cannot be caught or ignored. Use as last resort.
SIGSTOP19StopPause (freeze) a process. Cannot be caught or ignored.
SIGCONT18ContinueResume a stopped process.
# kill — send signal to process by PID $ kill 1234 # Send SIGTERM (graceful shutdown) $ kill -15 1234 # Same as above — explicit SIGTERM $ kill -9 1234 # SIGKILL — force kill (last resort) $ kill -1 1234 # SIGHUP — reload configuration $ kill -l # List all signal names and numbers # killall — kill by process name $ killall nginx # Kill all nginx processes $ killall -9 firefox # Force kill all firefox instances $ pkill -u student # Kill all processes owned by student $ pkill -f "backup.py" # Kill by full command line match
Slide 6 — Job Control: Background and Foreground

Foreground Jobs

A foreground job occupies your terminal — you must wait for it to complete before typing another command. Use Ctrl+C to terminate it or Ctrl+Z to suspend it.

$ ping google.com # Foreground — blocks terminal Ctrl+Z # Suspend (stop) the job $ fg # Resume in foreground $ fg %2 # Resume job number 2

Background Jobs

A background job runs without occupying the terminal. Append & to run it in background from the start, or use bg after suspending with Ctrl+Z.

$ ./backup.sh & # Start directly in background [1] 4521 # Job number and PID $ jobs # List background jobs $ bg %1 # Resume job 1 in background $ nohup ./task.sh & # Survive terminal logout
SECURITY NOTE: ZOMBIE AND HIDDEN PROCESSES

Malware often attempts to hide by manipulating process names, using kernel modules to remove themselves from process listings, or creating processes with names identical to legitimate system processes. When investigating a suspected compromise, use multiple methods: ps aux, ls /proc/ (each PID directory is a running process), lsof -p PID (open files), and compare the counts. A discrepancy between ps output and /proc/ directory entries is a rootkit indicator. Zombie processes in large numbers indicate a buggy parent process failing to reap children — not a security concern but worth investigating.

Presentation Complete

Mark complete to save your progress and unlock the Chapter 4 quiz.

Progress saved. Head to the quiz to test your knowledge.