LFCA 30 🐧 Viewing Running Processes
Every program running on a Linux system is a process. The shell you type into is a process. The web server serving a page is a process. The kernel’s background workers, the login session, the editor, the compiler — all processes. When something is slow, or a service is not responding, or a program is consuming all the memory, the answer is somewhere in the list of running processes. The tools for viewing them are the diagnostic foundation of the system: ps for a snapshot, top and htop for a live view, pgrep and pidof for finding a specific process, pstree for the parent-child relationships, and /proc for the raw data underneath. This chapter covers each tool, what it shows, when to reach for it, and how to read the output. It does not cover managing or killing processes — that is the next chapter — but it covers everything needed to see what is running and understand what the output means.
Key point: A process has a PID (process ID), a PPID (parent process ID), an owner (UID), a state, a command line, and a set of resources it uses (CPU, memory, open files). ps shows a snapshot of these, top and htop show them live, pgrep and pidof find processes by name, and pstree shows the parent-child tree. The /proc filesystem exposes the same data as files, and the tools are reading from it. Every process on the system is a descendant of PID 1, the init process (or systemd on modern systems), which is started by the kernel at boot.
What a process is
A process is a running instance of a program. The program is the file on disk; the process is the execution of it, with its own memory, its own file descriptors, its own state. The same program run twice produces two processes.
The PID. Every process has a unique process ID, assigned by the kernel when the process is created. The PID is the handle the kernel and the tools use to refer to the process. The first process is PID 1, and subsequent processes get increasing numbers until the counter wraps around and starts reusing PIDs that are no longer in use.
The PPID. Every process except PID 1 has a parent — the process that created it. The parent-child relationship forms a tree rooted at PID 1. When a process creates another, the new process’s PPID is the creator’s PID. The tree is how the system organizes processes, and pstree shows it.
The owner. Every process runs as a user, identified by a UID. The owner determines what the process is allowed to do — which files it can read, which signals it can send, which resources it can use. A process started by alice runs as alice unless it is a setuid program that changes its effective UID.
The state. A process is in one of several states: running (using the CPU), sleeping (waiting for something), stopped (paused), zombie (finished but not yet reaped by the parent). The state is a single letter in the ps output, and it tells you what the process is doing at the moment the snapshot was taken.
The command line. The arguments the process was started with. This is how ps distinguishes two instances of the same program — the command line is what was typed, and it usually includes the options and paths that make each instance unique.
Why processes are the unit of diagnosis. When the system is slow, some process is consuming CPU. When memory is exhausted, some process is holding it. When a service is unreachable, its process may have exited or may be stuck. Almost every system problem is a process problem, and the viewing tools are how the search begins.
Why the process tree matters. A process that creates children — a shell, a web server, a build tool — produces a subtree. When the parent exits, its children are reparented to PID 1 (or to a subreaper). The tree shows which processes belong together, which is essential for understanding what a service is actually running and for killing an entire group when needed.
ps — the snapshot tool
ps shows the processes running at the moment it is invoked. It does not update; it is a snapshot. The output depends on the options given, and the options come in three styles: Unix (with a dash), BSD (without a dash), and GNU (with long options). Mixing styles is discouraged.
The most common invocation is ps aux, which shows every process on the system with user-oriented columns.
$ ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.1 167436 11452 ? Ss Mar15 0:03 /sbin/init
root 2 0.0 0.0 0 0 ? S Mar15 0:00 [kthreadd]
alice 1234 0.5 1.2 1234567 98765 pts/0 Sl 10:22 0:15 /usr/bin/node app.jsThe columns are: the user, the PID, the CPU percentage, the memory percentage, the virtual memory size, the resident set size, the controlling terminal, the state, the start time, the cumulative CPU time, and the command.
Why ps aux is the default. It shows every process (the a), includes processes without a controlling terminal (the x), and displays user-oriented output (the u). The combination is the most informative for a general look at the system. The equivalent Unix-style invocation is ps -ef, which shows a slightly different column set but the same information.
Why the column meanings matter. %CPU is the CPU usage since the process started, averaged, not the instantaneous usage. %MEM is the percentage of physical memory the process is using. VSZ is the virtual memory size — the total address space the process has mapped, which can be much larger than the physical memory it is using. RSS is the resident set size — the physical memory actually in use. STAT is the state. TIME is the cumulative CPU time, not the wall-clock time since the process started.
The state letters. R is running or runnable. S is sleeping interruptibly. D is sleeping uninterruptibly, usually waiting for I/O. T is stopped. Z is zombie. The letters are often followed by modifiers: s for session leader, l for multi-threaded, + for in the foreground process group. A process in D state cannot be killed until the I/O completes, which is why D is the state to look for when a process seems stuck.
Filtering the output. ps can be filtered by user, by PID, by command name, and by many other criteria. The -u option selects by user, -p by PID, and -C by command name.
ps -u alice
ps -p 1234
ps -C nginxThe filters are how a large output is narrowed to the process of interest. They are also how scripts find processes without using the broader tools.
Why the same process can appear multiple times. A multi-threaded process shows as multiple lines in ps -eLf, which lists threads. A process with children shows once for itself and once for each child. A kernel thread shows in square brackets, like [kthreadd], and has no command path because it is not a user-space program.
top — the live view
top shows the processes sorted by resource usage and updates continuously. It is the tool for watching the system in motion.
$ top
top - 10:50:12 up 3 days, 2 users, load average: 0.15, 0.10, 0.05
Tasks: 123 total, 1 running, 122 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.3 us, 1.1 sy, 0.0 ni, 96.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 16000.0 total, 4000.0 free, 8000.0 used, 4000.0 buff/cache
MiB Swap: 2000.0 total, 1999.0 free, 1.0 used. 7000.0 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1234 alice 20 0 1234567 98765 12345 S 0.5 1.2 0:15.23 nodeThe header shows the system summary: the current time, uptime, load average, task counts, CPU usage broken down by category, memory usage, and swap usage. The body shows the processes, sorted by CPU by default.
Why the load average matters. The load average is the average number of processes waiting to run over the last 1, 5, and 15 minutes. On a single-core system, a load average of 1.0 means the CPU is fully utilized. On a multi-core system, the threshold is the number of cores. A load average that is much higher than the core count indicates contention — processes are waiting for CPU time.
Why the CPU breakdown matters. The categories are us (user), sy (system), ni (niced), id (idle), wa (I/O wait), hi (hardware interrupts), si (software interrupts), and st (stolen by a hypervisor). A high wa means processes are waiting for disk or network I/O, which is a different problem from high CPU usage. A high st means the virtual machine is not getting the CPU time it should.
The interactive keys. top accepts keystrokes while running. q quits. M sorts by memory. P sorts by CPU. k kills a process by PID. 1 shows per-core CPU usage. h shows the help. These keys are what make top interactive, and they are worth learning.
Why top is available everywhere. top is part of the procps or procps-ng package, which is installed on almost every Linux system by default. It is the tool that will be present when a minimal system is being diagnosed, which is why it is worth knowing even if a nicer alternative is preferred.
htop — the friendlier alternative
htop is an enhanced version of top with color, mouse support, and a more readable layout. It is not installed by default on most systems, but it is a small package and widely used.
sudo apt install htop
htopThe header shows the same information as top, with per-core CPU bars, memory and swap bars, and the load average. The body shows the processes in a tree by default, with color-coded states and a highlighted selection.
Why htop is easier to use. The function keys at the bottom show the available actions: F3 for search, F4 for filter, F5 for tree view, F6 for sort, F9 for kill. The actions are discoverable, and the color makes the state and the resource usage visible at a glance. For a user who is not already fluent in top, htop is the easier entry point.
Why htop is not always available. It is a separate package, and a minimal server or a rescue environment may not have it. When it is present, it is the better tool; when it is absent, top is the fallback. Knowing both means being prepared for either environment.
Why the tree view is useful. htop‘s tree view (F5) shows the parent-child relationships in place, with the children indented under their parents. This makes it immediately clear which processes belong to a service or a session, and it is often faster than running pstree separately.
Finding a specific process
When the goal is to find a process by name rather than to view everything, the query tools are faster and produce cleaner output.
pgrep finds processes by name and other criteria.
pgrep nginx
# 1234
# 1235
# 1236The output is just the PIDs, one per line, which makes it ideal for scripts. The -a flag shows the command line alongside the PID, and -l shows the process name.
pgrep -a nginx
# 1234 nginx: master process /usr/sbin/nginx
# 1235 nginx: worker processWhy pgrep is preferred over ps | grep. The ps aux | grep nginx pattern is common but has two problems: it matches the grep command itself, and it matches any command line containing the string, not just the process name. pgrep matches the process name by default, excludes itself, and returns clean PIDs. It is the correct tool.
pidof is simpler but narrower.
pidof nginx
# 1234 1235 1236The output is space-separated PIDs on one line. pidof matches the executable name exactly, which is more precise than a substring match but less flexible than pgrep.
pstree shows the tree.
pstree -p
# systemd(1)─┬─systemd-journal(456)
# ├─systemd-udevd(789)
# ├─sshd(1234)───sshd(1235)───bash(1236)───pstree(1237)
# └─nginx(1238)─┬─nginx(1239)
# └─nginx(1240)The -p flag shows PIDs alongside the names. The tree structure makes the parent-child relationships visible, which is essential for understanding what a service is running and for finding the parent of a process that should be killed as a group.
Why pstree is useful for services. A web server, a database, or a container runtime often runs a master process that spawns workers. The pstree output shows the master and all its workers together, which ps shows as a flat list. The tree is the correct mental model for these processes.
ps -ef --forest is the ps equivalent.
ps -ef --forestThe --forest option indents the output to show the tree, using the same parent-child relationships that pstree shows. It is a way to get the tree from ps without a separate command.
Why the parent matters for management. Killing a parent process often kills its children, but not always. Killing a child leaves the parent running. Knowing the tree tells you which process to target and what the effect will be. A signal sent to the wrong process in a tree can leave the service in a partial state, which is harder to diagnose than the original problem.
The /proc filesystem
Every process has a directory in /proc named by its PID. The directory contains files that expose the process’s state, and the tools like ps and top are reading from these files.
ls /proc/1234
# attr cmdline cwd environ exe fd maps mem root stat status ...
cat /proc/1234/cmdline | tr '\0' ' '
# /usr/bin/node app.js
cat /proc/1234/status
# Name: node
# State: S (sleeping)
# Pid: 1234
# PPid: 1230
# Uid: 1000 1000 1000 1000
# Gid: 1000 1000 1000 1000
# VmRSS: 98765 kB
# ...
ls -l /proc/1234/cwd
# lrwxrwxrwx ... /proc/1234/cwd -> /home/alice/app
ls -l /proc/1234/fd
# total 0
# lrwx------ 1 alice alice 64 Mar 15 10:00 0 -> /dev/pts/0
# lrwx------ 1 alice alice 64 Mar 15 10:00 1 -> /dev/pts/0
# lrwx------ 1 alice alice 64 Mar 15 10:00 2 -> /dev/pts/0Why /proc is useful. The files expose the raw data that the tools format. The cwd symlink shows the working directory of the process. The exe symlink shows the executable path. The fd directory shows every open file descriptor, which is how you find which file a process has open, or which socket it is connected to. The environ file shows the environment variables the process was started with.
Why cmdline uses null separators. The command line arguments in /proc/PID/cmdline are separated by null bytes, not spaces, so that arguments containing spaces are preserved unambiguously. The tr '\0' ' ' converts them to spaces for display.
Why the fd directory is useful for diagnosis. A process that has run out of file descriptors has a full fd directory. A process that is holding a deleted file open — a common cause of disk space not being freed — shows the file with (deleted) next to it in the fd listing. These are not visible from ps or top, and /proc is the only way to see them.
Why the status file is the structured view. The stat file is the machine-readable form, and status is the human-readable form. status includes the name, state, PID, PPID, UIDs, GIDs, memory usage, and thread count. It is the file to read when a script needs a specific field.
Complete Example Session
# ============================================
# PART 1: PS AUX
# ============================================
ps aux | head -5
# USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
# root 1 0.0 0.1 167436 11452 ? Ss Mar15 0:03 /sbin/init
# root 2 0.0 0.0 0 0 ? S Mar15 0:00 [kthreadd]
# root 3 0.0 0.0 0 0 ? I< Mar15 0:00 [rcu_gp]
# root 4 0.0 0.0 0 0 ? I< Mar15 0:00 [rcu_par_gp]
# ============================================
# PART 2: PS WITH FILTERS
# ============================================
ps -u alice
# Shows only alice's processes
ps -C nginx
# Shows only processes named nginx
ps -ef --forest | head -20
# Shows the process tree with indentation
# ============================================
# PART 3: STATE LETTERS
# ============================================
ps aux | awk '$8 ~ /^[RD]/ { print $2, $8, $11 }'
# Lists running and uninterruptible processes
# R = running
# D = uninterruptible sleep (I/O wait)
# ============================================
# PART 4: TOP
# ============================================
top
# q to quit
# M to sort by memory
# P to sort by CPU
# 1 to show per-core usage
# k to kill by PID
# h for help
# ============================================
# PART 5: HTOP
# ============================================
sudo apt install htop
htop
# F3 search
# F4 filter
# F5 tree view
# F6 sort by column
# F9 kill
# ============================================
# PART 6: PGREP
# ============================================
pgrep nginx
# 1234
# 1235
# 1236
pgrep -a nginx
# 1234 nginx: master process /usr/sbin/nginx
# 1235 nginx: worker process
# 1236 nginx: worker process
pgrep -u alice
# All of alice's process PIDs
# ============================================
# PART 7: PIDOF
# ============================================
pidof nginx
# 1234 1235 1236
pidof sshd
# 1230
# ============================================
# PART 8: PSTREE
# ============================================
pstree -p | head -20
# systemd(1)─┬─systemd-journal(456)
# ├─systemd-udevd(789)
# ├─sshd(1230)───sshd(1231)───bash(1232)───pstree(1233)
# └─nginx(1234)─┬─nginx(1235)
# └─nginx(1236)
pstree -p 1234
# Shows only the subtree rooted at PID 1234
# ============================================
# PART 9: /PROC
# ============================================
cat /proc/1/cmdline | tr '\0' ' '
# /sbin/init
cat /proc/1/status | head
# Name: systemd
# Umask: 0022
# State: S (sleeping)
# Tgid: 1
# Ngid: 0
# Pid: 1
# PPid: 0
# ...
ls -l /proc/1/cwd
# lrwxrwxrwx ... /proc/1/cwd -> /
ls -l /proc/1/fd | head
# lrwx------ 1 root root 64 ... 0 -> /dev/null
# lrwx------ 1 root root 64 ... 1 -> /dev/null
# lrwx------ 1 root root 64 ... 2 -> /dev/null
# ...
# ============================================
# PART 10: FINDING A PROCESS BY PORT
# ============================================
sudo ss -tlnp | grep :80
# LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=1234,fd=6))
# ============================================
# PART 11: MEMORY HOGS
# ============================================
ps aux --sort=-%mem | head -5
# USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
# alice 1234 0.5 12.5 1234567 987654 pts/0 Sl 10:22 0:15 node app.js
# ...
# ============================================
# PART 12: CPU HOGS
# ============================================
ps aux --sort=-%cpu | head -5
# USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
# alice 5678 95.0 2.5 2345678 234567 pts/0 R 10:30 5:15 ffmpeg
# ...The twelve parts cover the snapshot tools, the live tools, the query tools, the tree, /proc, and the common diagnostic queries.
Quick Reference
Process Tools
| Tool | Purpose |
|---|---|
ps | Snapshot of processes |
top | Live view, sorted by CPU |
htop | Live view with color and mouse |
pgrep | Find PIDs by name/criteria |
pidof | Find PIDs by exact name |
pstree | Process tree |
ss | Sockets and listening ports |
ps Common Invocations
| Command | Shows |
|---|---|
ps aux | All processes, user columns |
ps -ef | All processes, full format |
ps -u user | Processes by user |
ps -C name | Processes by command name |
ps -p pid | Specific PID |
ps -ef --forest | Process tree |
ps aux --sort=-%mem | Sorted by memory |
ps aux --sort=-%cpu | Sorted by CPU |
ps aux Columns
| Column | Meaning |
|---|---|
USER | Owner |
PID | Process ID |
%CPU | CPU usage since start |
%MEM | Memory usage percentage |
VSZ | Virtual memory size |
RSS | Resident set size |
TTY | Controlling terminal |
STAT | State |
START | Start time |
TIME | Cumulative CPU time |
COMMAND | Command line |
Process States
| Letter | Meaning |
|---|---|
R | Running or runnable |
S | Sleeping (interruptible) |
D | Uninterruptible sleep (I/O) |
T | Stopped |
Z | Zombie |
I | Idle kernel thread |
top Keys
| Key | Action |
|---|---|
q | Quit |
M | Sort by memory |
P | Sort by CPU |
1 | Per-core CPU |
k | Kill by PID |
h | Help |
c | Show full command |
htop Keys
| Key | Action |
|---|---|
F3 | Search |
F4 | Filter |
F5 | Tree view |
F6 | Sort |
F9 | Kill |
F10 | Quit |
/proc/PID Files
| File | Contents |
|---|---|
cmdline | Command line (null-separated) |
status | Human-readable status |
stat | Machine-readable status |
cwd | Symlink to working directory |
exe | Symlink to executable |
fd/ | Open file descriptors |
environ | Environment variables |
maps | Memory mappings |
Best Practices
✅ Do This:
# Use ps aux for a quick overview
ps aux | head -20 # ✅
# Filter by user for a specific user's processes
ps -u alice # ✅
# Sort by resource usage
ps aux --sort=-%mem | head -10 # ✅
# Use pgrep instead of ps | grep
pgrep -a nginx # ✅
# Use pstree to see parent-child relationships
pstree -p 1234 # ✅
# Check /proc for details not in ps
cat /proc/1234/status # ✅
# Find which process listens on a port
sudo ss -tlnp | grep :80 # ✅
# Use top or htop for live monitoring
htop # ✅❌ Don’t Do This:
# Don't use ps aux | grep for scripting
ps aux | grep nginx # matches grep itself, unreliable # ⚠️
# Don't assume %CPU is instantaneous
ps aux # %CPU is since process start, not current # ⚠️
# Don't confuse VSZ with actual memory
# VSZ includes mapped but unused memory # ⚠️
# Don't ignore D state processes
# They are stuck in I/O and cannot be killed # ⚠️
# Don't kill processes without understanding the tree
# Killing a parent may orphan children unexpectedly # ⚠️
# Don't rely on htop being installed
# On minimal systems, top is the fallback # ⚠️Common Pitfalls
| Pitfall | Problem | Solution |
|---|---|---|
ps aux | grep matches grep | False positive | Use pgrep |
%CPU misread as current | It is averaged since start | Use top for current |
VSZ mistaken for RAM use | Virtual, not resident | Check RSS |
D state ignored | Process stuck in I/O | Investigate the I/O |
Z state ignored | Zombie indicates parent issue | Check the parent |
htop not installed | Command not found | Install or use top |
| Tree not checked | Wrong process killed | Use pstree |
/proc not considered | Missing detail | Check status, fd |
Real-World Examples
1. All processes
ps aux2. A specific user’s processes
ps -u www-data3. A specific program
ps -C nginx4. Sorted by memory
ps aux --sort=-%mem | head -105. Sorted by CPU
ps aux --sort=-%cpu | head -106. Process tree
pstree -p7. Find by name
pgrep -a node8. Live monitoring
htop9. Listening process
sudo ss -tlnp | grep :44310. Details from /proc
cat /proc/1234/statusVisual: The Process Tree
┌──────────────────────────────────────────────────────────┐
│ systemd (PID 1) │
│ │ │
│ ├── systemd-journald (456) │
│ ├── systemd-udevd (789) │
│ ├── sshd (1230) │
│ │ └── sshd (1231) │
│ │ └── bash (1232) │
│ │ └── vim (1233) │
│ │ │
│ ├── nginx (1234) master │
│ │ ├── nginx (1235) worker │
│ │ └── nginx (1236) worker │
│ │ │
│ └── node (1240) │
│ └── node (1241) worker │
│ │
│ Every process descends from PID 1. │
│ The tree shows which processes belong together. │
│ │
└──────────────────────────────────────────────────────────┘Visual: ps aux Columns
┌──────────────────────────────────────────────────────────┐
│ USER PID %CPU %MEM VSZ RSS TTY STAT START TIME │
│ │ │ │ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ │ │ └── cumulative│
│ │ │ │ │ │ │ │ │ └─────── start time│
│ │ │ │ │ │ │ │ └──────────── state│
│ │ │ │ │ │ │ └───────────────── terminal│
│ │ │ │ │ │ └────────────────────── resident memory│
│ │ │ │ │ └──────────────────────────── virtual memory│
│ │ │ │ └──────────────────────────────────── memory %│
│ │ │ └───────────────────────────────────────── CPU %│
│ │ └────────────────────────────────────────────── process ID│
│ └───────────────────────────────────────────────────── owner│
│ │
│ %CPU and %MEM are averages since start. │
│ RSS is the actual physical memory in use. │
│ │
└──────────────────────────────────────────────────────────┘Visual: Process States
┌──────────────────────────────────────────────────────────┐
│ R Running or runnable │
│ Using the CPU or waiting in the run queue. │
│ │
│ S Sleeping (interruptible) │
│ Waiting for an event, can be woken by a signal. │
│ The most common state. │
│ │
│ D Uninterruptible sleep │
│ Waiting for I/O. Cannot be killed until the I/O │
│ completes. The state to investigate when a process │
│ seems stuck. │
│ │
│ T Stopped │
│ Paused by a signal (Ctrl+Z or SIGSTOP). │
│ │
│ Z Zombie │
│ Finished but not reaped by the parent. │
│ Consumes no resources but occupies a PID. │
│ │
│ I Idle kernel thread │
│ │
└──────────────────────────────────────────────────────────┘Visual: top Header
┌──────────────────────────────────────────────────────────┐
│ top - 10:50:12 up 3 days, 2 users, load average: │
│ 0.15, 0.10, 0.05 │
│ │
│ Tasks: 123 total, 1 running, 122 sleeping, 0 zombie │
│ │
│ %Cpu(s): 2.3 us, 1.1 sy, 0.0 ni, 96.5 id, 0.0 wa │
│ │ │ │ │ │
│ │ │ │ └── I/O wait │
│ │ │ └── idle │
│ │ └── system │
│ └── user │
│ │
│ MiB Mem : 16000 total, 4000 free, 8000 used, 4000 cache │
│ MiB Swap: 2000 total, 1999 free, 1 used │
│ │
│ Load average is the key health metric. │
│ Compare it to the number of CPU cores. │
│ │
└──────────────────────────────────────────────────────────┘Visual: /proc/PID
┌──────────────────────────────────────────────────────────┐
│ /proc/1234/ │
│ │ │
│ ├── cmdline command line (null-separated) │
│ ├── status name, state, PID, PPID, UIDs, memory │
│ ├── stat machine-readable status │
│ ├── cwd ──► symlink to working directory │
│ ├── exe ──► symlink to executable │
│ ├── root ──► symlink to root directory │
│ ├── environ environment variables │
│ ├── fd/ open file descriptors │
│ │ 0 ──► stdin │
│ │ 1 ──► stdout │
│ │ 2 ──► stderr │
│ ├── maps memory mappings │
│ └── ... │
│ │
│ ps and top read from these files. │
│ │
└──────────────────────────────────────────────────────────┘Visual: Finding a Process
┌──────────────────────────────────────────────────────────┐
│ What do you need? │
│ │ │
│ ├── A quick overview of everything │
│ │ └── ps aux │
│ │ │
│ ├── A live view │
│ │ └── top or htop │
│ │ │
│ ├── A specific process by name │
│ │ └── pgrep -a name │
│ │ │
│ ├── A process by port │
│ │ └── ss -tlnp | grep :port │
│ │ │
│ ├── The parent-child tree │
│ │ └── pstree -p │
│ │ │
│ ├── The biggest memory user │
│ │ └── ps aux --sort=-%mem | head │
│ │ │
│ └── Details not in ps │
│ └── cat /proc/PID/status │
│ │
└──────────────────────────────────────────────────────────┘Summary
| Tool | Purpose | Updates |
|---|---|---|
ps | Snapshot | No |
top | Live view | Yes |
htop | Live view, color | Yes |
pgrep | Find by name | Once |
pidof | Find by exact name | Once |
pstree | Process tree | Once |
ss | Sockets and ports | Once |
/proc | Raw data | Live |
| Concept | Meaning |
|---|---|
| PID | Process ID |
| PPID | Parent process ID |
| UID | Owner |
| STAT | State |
| RSS | Physical memory |
| VSZ | Virtual memory |
| %CPU | Average since start |
| Load average | Waiting processes over 1/5/15 min |
Key takeaways:
- A process is a running instance of a program — it has a PID, a parent, an owner, a state, and a command line
ps auxis the snapshot — a single view of every process with user-oriented columns, and the columns have specific meanings that are easy to misread%CPUis an average since the process started, not the current usage —topshows the current usage, which is why it is the tool for a live viewRSSis the physical memory in use;VSZis the virtual address space —VSZis often much larger and is not the measure of actual memory consumption- The state letter tells you what the process is doing —
Rrunning,Ssleeping,Dstuck in I/O,Zzombie, andDis the state to investigate when a process cannot be killed topis everywhere;htopis friendlier —topis part of the base system, andhtopis a small package that adds color, mouse support, and discoverable keyspgrepis the correct tool for finding a process by name — it returns clean PIDs, excludes itself, and avoids theps | grepfalse positivepstreeshows the parent-child relationships — essential for understanding what a service is running and for knowing which process to target/proc/PIDexposes the raw data —cmdline,status,cwd,exe,fd, andenvironshow details thatpsandtopdo not, including open file descriptors and the working directory- The load average is the health metric — compare it to the number of cores to determine whether the system is contended
Remember: Viewing running processes is the first step in almost every diagnosis. ps gives the snapshot, top and htop give the live view, pgrep finds a specific process, pstree shows the tree, and /proc shows the raw data. Knowing which tool to reach for and how to read its output is what turns a system problem from a mystery into a specific process with a specific state and a specific resource consumption. The next chapter covers what to do about it — signals and process management.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!