Linux Process Management — Mastering ps, top, kill & Process Lifecycle

---

🎯 What You Will Learn

• How to inspect all running processes using ps aux and ps -ef with full output interpretation
• How to monitor system processes in real time using top and htop
• How to terminate processes cleanly and forcefully using kill and killall
• What PID and PPID mean and why the parent-child process relationship matters
• What a zombie process is, why it forms, and how to deal with it

---

📝 Topic Overview

---

🔹 ps aux — BSD-Style Full Process Snapshot

ps (process status) prints a snapshot of currently running processes. The aux flags are the most commonly used combination.

Flag breakdown:

• a — show processes from all users (not just the current user)
• u — show in user-oriented format (adds USER, CPU%, MEM% columns)
• x — include processes not attached to a terminal (daemons, background services)

ps aux

Sample output and column meanings:

Column	Meaning
USER	Owner of the process
PID	Process ID — unique identifier
%CPU	CPU usage since process started
%MEM	Physical RAM usage percentage
VSZ	Virtual memory size (KB) — total address space reserved
RSS	Resident Set Size (KB) — actual RAM currently in use
TTY	Terminal associated with the process (? = no terminal/daemon)
STAT	Process state (see state codes below)
START	Time or date the process started
TIME	Total accumulated CPU time used
COMMAND	Command that launched the process

Process state codes (STAT column):

Code	Meaning
R	Running or runnable (on the CPU or ready queue)
S	Interruptible sleep (waiting for an event, e.g., I/O)
D	Uninterruptible sleep (usually waiting on disk I/O — cannot be killed)
Z	Zombie — process finished but not yet reaped by parent
T	Stopped (via SIGSTOP or Ctrl+Z)
<	High priority (negative nice value)
N	Low priority (positive nice value)
s	Session leader (e.g., a shell)
l	Multi-threaded process
+	In the foreground process group

# Filter ps output for a specific process name
ps aux | grep nginx

# Sort by CPU usage (highest first)
ps aux --sort=-%cpu | head -10

# Sort by memory usage (highest first)
ps aux --sort=-%mem | head -10

---

🔹 ps -ef — POSIX/System V Style Process Listing

ps -ef is the System V (POSIX) style equivalent — standard across all Unix-like systems including macOS, Solaris, and AIX.

Flag breakdown:

• -e — show every process on the system
• -f — full format listing (adds PPID, STIME, UID columns)

ps -ef

Key columns unique to -ef:

Column	Meaning
UID	User ID (owner)
PID	Process ID
PPID	Parent Process ID — the PID that spawned this process
C	CPU utilization integer
STIME	Start time
TTY	Terminal
TIME	CPU time consumed
CMD	Full command with arguments

ps aux vs ps -ef: Both show all processes. aux gives %CPU, %MEM, VSZ, RSS — better for resource analysis. -ef shows PPID natively — better for tracing the process tree. Combine them: ps auxf adds an ASCII tree visualization.

# Show process tree using ps
ps auxf

# Find parent-child chain for a specific PID
ps -ef | grep <PID>

---

🔹 top — Real-Time Interactive Process Monitor

top is a live, continuously refreshing view of system resource usage and process activity. It updates every 3 seconds by default.

top

Real output example:

top - 18:16:43 up  4:20,  1 user,  load average: 0.42, 0.53, 0.61
Tasks: 341 total,   1 running, 340 sleeping,   0 stopped,   0 zombie
%Cpu(s):  4.4 us,  1.6 sy,  0.3 ni, 92.5 id,  1.1 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   7722.0 total,    826.3 free,   4203.1 used,   2692.6 buff/cache
MiB Swap:  11817.5 total,  10912.4 free,    905.1 used.   2239.7 avail Mem

---

Line 1 — System Summary

top - 18:16:43 up 4:20, 1 user, load average: 0.42, 0.53, 0.61

Field	Value	Meaning
Current time	18:16:43	Wall clock time when this snapshot was taken
Uptime	up 4:20	System has been running for 4 hours 20 minutes
Users	1 user	One user session currently logged in
Load avg (1m)	0.42	Average number of runnable/waiting processes over last 1 minute
Load avg (5m)	0.53	Same, over last 5 minutes
Load avg (15m)	0.61	Same, over last 15 minutes

Reading load averages: Load average represents the average number of processes that are either running or waiting for CPU time. On a single-core machine, a load of 1.0 means 100% busy. On a 4-core machine, a load of 4.0 means 100% busy. This system has 1 user and a load of 0.42 — the CPU is largely idle and healthy. A load average trending upward (0.42 → 0.53 → 0.61 reading right to left = rising load) can be a warning sign of increasing pressure.

---

Line 2 — Task (Process) Summary

Tasks: 341 total, 1 running, 340 sleeping, 0 stopped, 0 zombie

Field	Value	Meaning
Total	341	Total number of processes currently known to the kernel
Running	1	Processes actively on a CPU core right now
Sleeping	340	Processes waiting on I/O, timers, or events (normal)
Stopped	0	Processes paused via SIGSTOP or Ctrl+Z
Zombie	0	Dead processes not yet reaped by their parent

What’s normal: Having nearly all processes sleeping is completely healthy — it means they’re idle and waiting for work. 0 zombie is the ideal state. If zombie count climbs steadily, a parent process has a bug and isn’t calling wait().

---

Line 3 — CPU Usage Breakdown

%Cpu(s):  4.4 us,  1.6 sy,  0.3 ni, 92.5 id,  1.1 wa,  0.0 hi,  0.0 si,  0.0 st

Field	Value	Meaning
us	4.4%	User space — CPU time spent running your applications
sy	1.6%	System/kernel — CPU time spent on kernel operations (syscalls, drivers)
ni	0.3%	Nice — CPU time for user processes with adjusted (lowered) priority
id	92.5%	Idle — CPU doing nothing; available capacity
wa	1.1%	I/O wait — CPU idle but waiting for disk/network I/O to complete
hi	0.0%	Hardware interrupts — time handling hardware signals (keyboard, NIC)
si	0.0%	Software interrupts — time handling kernel software interrupt processing
st	0.0%	Steal time — CPU cycles taken by the hypervisor (only non-zero in VMs)

Reading this snapshot: 92.5% idle means the system is under very light load. 1.1% wa (I/O wait) is low and normal. If wa climbs above 10–20%, you likely have a disk bottleneck. If sy is consistently high, kernel-level activity (syscalls, context switches) may be a concern. st > 0 on a VM signals the host hypervisor is overcommitted.

---

Line 4 — Physical Memory (RAM)

MiB Mem : 7722.0 total, 826.3 free, 4203.1 used, 2692.6 buff/cache

Field	Value	Meaning
total	7722.0 MiB	Total installed physical RAM (~7.5 GB)
free	826.3 MiB	Completely unused RAM
used	4203.1 MiB	RAM actively used by processes
buff/cache	2692.6 MiB	RAM used by kernel for disk buffers and file cache

Don’t panic about low “free” memory. Linux aggressively uses spare RAM as disk cache (buff/cache) to speed up file access. This memory is immediately reclaimable when a process needs it. The real available memory is shown on the Swap line as avail Mem — here 2239.7 MiB is truly available for new allocations.

---

Line 5 — Swap Space

MiB Swap: 11817.5 total, 10912.4 free, 905.1 used. 2239.7 avail Mem

Field	Value	Meaning
total	11817.5 MiB	Total swap space (~11.5 GB, on disk)
free	10912.4 MiB	Unused swap
used	905.1 MiB	Data currently swapped out to disk
avail Mem	2239.7 MiB	Estimated RAM available for new processes without swapping

Swap in use (905.1 MiB) means some memory pages were moved to disk — likely from long-idle processes. Moderate swap use is fine. Heavy swap use (swap used near total) combined with high wa CPU time is a classic sign of memory pressure — the system is constantly swapping pages in and out, causing slowdowns.

---

Interactive keyboard shortcuts inside top:

Key	Action
P	Sort by CPU usage
M	Sort by memory usage
k	Kill a process (prompts for PID and signal)
r	Renice a process (change priority)
u	Filter by a specific user
1	Toggle per-CPU-core breakdown
h	Help screen
q	Quit

---

🔹 htop — Enhanced Interactive Process Viewer

htop is a modern, color-coded, mouse-enabled alternative to top. It is not installed by default on all systems.

# Install if not present
sudo apt install htop      # Debian/Ubuntu
sudo dnf install htop      # Fedora/RHEL

htop

Advantages over top:

• Visual CPU/memory bars per core
• Mouse-clickable interface
• Scroll horizontally to see full command lines
• Multi-select and bulk-kill processes (Space to select, F9 to kill)
• Tree view built in (F5)

Key shortcuts:

Key	Action
F2	Setup / configuration
F3	Search for a process by name
F4	Filter processes
F5	Tree view (shows parent-child hierarchy)
F6	Sort by column
F9	Kill selected process (choose signal)
F10	Quit

---

🔹 kill — Send Signals to a Process by PID

kill does not only terminate processes — it sends signals to them. Termination is just the most common use.

# Syntax
kill [signal] <PID>

# Default signal is SIGTERM (15) — polite termination request
kill 1234

# Force kill with SIGKILL (9) — cannot be caught or ignored
kill -9 1234

# List all available signals
kill -l

Essential signals:

Signal	Number	Meaning
SIGTERM	15	Graceful termination request — process can clean up
SIGKILL	9	Immediate, unconditional kill — cannot be caught
SIGHUP	1	Hangup — often used to reload config (e.g., nginx, sshd)
SIGSTOP	19	Pause/suspend a process (cannot be caught)
SIGCONT	18	Resume a stopped process
SIGINT	2	Interrupt (same as pressing Ctrl+C)

Best practice: Always try SIGTERM (15) first — it allows the process to save state and exit cleanly. Only escalate to SIGKILL (9) if the process doesn’t respond after a few seconds. SIGKILL cannot be intercepted; it is handled entirely by the kernel.

---

🔹 killall — Send Signals to Processes by Name

killall targets processes by name rather than PID — useful when you don’t know or want to look up the PID.

# Gracefully terminate all processes named "nginx"
killall nginx

# Force kill all instances
killall -9 firefox

# Kill only processes owned by a specific user
killall -u www-data nginx

# Interactively confirm before killing each match
killall -i python3

Warning: killall on Linux kills by name; on some Unix systems (e.g., Solaris), killall kills every single process on the system. Always verify which OS you’re on before using it in scripts.

---

🔹 PID and PPID — The Process Identity System

PID (Process ID): A unique integer assigned by the kernel to every process at creation. PIDs are assigned sequentially and wrap around after reaching the system maximum (typically 32768 by default, configurable via /proc/sys/kernel/pid_max).

PPID (Parent Process ID): The PID of the process that created (forked) this process. Every process except PID 1 has a parent.

Special PIDs:

PID	Process	Role
0	Swapper/idle	Kernel internal — not a real user process
1	init / systemd	The first userspace process; parent of all orphaned processes
2	kthreadd	Parent of all kernel threads

# Find PID of a running process by name
pgrep nginx

# Find PID and PPID together
ps -o pid,ppid,comm -p $(pgrep bash)

# Read a process's own PID/PPID from /proc
cat /proc/$$/status | grep -E "^(Pid|PPid)"

---

🔹 Zombie Processes — The Living Dead

A zombie process (state Z in ps) is a process that has finished executing but whose exit status has not yet been collected by its parent.

How a zombie forms:

1. Child process calls exit() — it terminates and releases its memory and resources.
2. The kernel keeps a small entry in the process table to store the exit code.
3. The parent is expected to call wait() or waitpid() to collect that exit code.
4. If the parent never calls wait(), the child entry stays in the process table forever — it becomes a zombie.

Key facts about zombies:

• A zombie holds no memory, no CPU — it’s just a process table entry
• You cannot kill a zombie with kill -9 — it’s already dead
• To eliminate a zombie, you must fix or kill its parent
• If the parent dies, systemd/init (PID 1) adopts the zombie and reaps it automatically

# Find zombie processes
ps aux | grep 'Z'
ps -el | grep Z

# Find the parent of a zombie (to kill it)
ps -o ppid= -p <zombie_PID>
kill -9 <parent_PID>   # killing the parent forces PID 1 to adopt and reap the zombie

Zombie vs Orphan: A zombie is a dead child whose parent hasn’t called wait(). An orphan is a living child whose parent has already died — orphans are immediately re-parented to PID 1 (systemd), which will properly reap them when they finish.

---

🔧 Commands & Quick Reference

Command	Purpose	Example
ps aux	Snapshot of all processes (BSD format)	ps aux \| grep nginx
ps -ef	Snapshot with PPID visible (POSIX format)	ps -ef \| grep python
ps auxf	Process tree in ASCII art	ps auxf \| less
top	Real-time process monitor	top then press P
htop	Enhanced real-time monitor	htop then F5 for tree
kill <PID>	Send SIGTERM to a process	kill 4321
kill -9 <PID>	Force kill (SIGKILL)	kill -9 4321
kill -1 <PID>	Reload config (SIGHUP)	kill -1 $(pgrep nginx)
killall <name>	Kill all processes by name	killall -9 firefox
pgrep <name>	Find PID by process name	pgrep sshd
pkill <name>	Kill by name (like killall)	pkill -9 zombie_app

---

💡 References & Learning Resources

• man ps, man top, man kill — the primary source of truth (Beginner-friendly)
• “The Linux Programming Interface” by Michael Kerrisk, Ch. 26 (Monitoring Child Processes) (Advanced/Deep dive)
• “Linux Command Line and Shell Scripting Bible” by Richard Blum (Beginner-friendly)
• strace -e trace=process ls — trace only process-related syscalls live (Intermediate)
• Linux proc(5) man page: man 5 proc — full reference for /proc/<PID>/status fields (Intermediate)

---

📊 Quick Recap

• ps aux is your go-to snapshot tool; %CPU, %MEM, RSS, and the STAT column reveal process health at a glance.
• ps -ef uniquely shows PPID, making it ideal for tracing parent-child relationships.
• top gives real-time CPU/memory stats; htop adds color, mouse support, and a tree view — prefer htop for interactive use.
• Always attempt SIGTERM (15) before SIGKILL (9) — give processes the chance to clean up gracefully.
• killall targets by name; kill targets by PID — use pgrep to bridge them: kill $(pgrep nginx).
• PID identifies a process uniquely; PPID reveals who spawned it, forming the process family tree rooted at PID 1 (systemd).
• A zombie is a finished process whose exit status was never collected by its parent — it holds no resources but cannot be removed until the parent calls wait() or dies itself.

---

🏷️ Tags

#Linux #ProcessManagement #ps #top #htop #kill #killall #PID #PPID #ZombieProcess #Signals #SIGTERM #SIGKILL #SystemMonitoring #CLI #Intermediate #SysAdmin #UnixInternals