htop: interactive process monitor

Why htop instead of top

top is always present, but it is read-only by default, sorts in a single fixed order, and shows no process tree. htop is color-coded, interactive, and supports mouse clicks. On modern distros it is typically the first package installed after setting up a system.

Alternatives: btop (better visuals, graphs), glances (includes network and disk), atop (disk load history). htop is the de facto standard.

Starting htop

htop                       # all processes

htop -u user               # only a specific user's processes

htop -p $(pgrep nginx)     # only nginx PIDs

htop -t                    # open directly in tree mode

htop --filter=nginx        # filter by name

What the top meters show

Default layout:

CPU   [|||||||||                    25%]

Mem   [||||||||||||                3.2G/16G]

Swp   [                            0K/2G]

• Each CPU core has its own bar (can be merged into an average).
• CPU colors: green = user, red = kernel, blue = low-priority, orange = iowait.
• Mem colors: green = used, blue = buffers, yellow = cache (cache is not lost memory).
• Tasks: total | running | threads.
• Load average and uptime.

In F2 Setup → Meters you can add: Hostname, temperature (Temperature), battery, network (netio), disk, ZFS ARC.

F-keys (or Esc combinations)

Search (F3) finds the first match; press F3 again for the next one. Filter (F4) hides everything except matches. Esc clears the filter.

Tree mode (F5)

Shows the parent to child hierarchy. Useful for understanding what launched what:

systemd

 ├─ sshd

 │   └─ sshd: user

 │       └─ bash

 │           └─ htop

 ├─ nginx

 │   ├─ nginx: worker

 │   └─ nginx: worker

 └─ postgres

     ├─ postgres: writer

     └─ postgres: checkpointer

This helps you find which parent is spawning zombie children.

Useful columns

Add via F2 → Columns:

• CGROUP: the cgroup the process belongs to (shows systemd units and containers).
• OOM: oom_score. The higher the score, the more likely the process is to be hit by [[oom-killer|OOM-killer]].
• IO_RATE: read/write rate (requires root and --enable-delayacct).
• STARTTIME: when the process was started.
• PROCESSOR: which CPU is executing the process.
• NLWP: thread count.

Color cues

• Yellow process name: kernel thread.
• Red PID: process is in state D (uninterruptible sleep, usually waiting on I/O).
• Space-marked entries: selected; F9 will send a signal to all of them.

How to kill a process through htop

1. Find the process (F3 or mouse).
2. Press F9 to open the signal menu.
3. Choose: SIGTERM (15) for a clean exit, SIGKILL (9) to force-terminate.

Between TERM and KILL: SIGINT (2) is equivalent to Ctrl+C; SIGHUP (1) usually triggers a reload without a restart. See signals for details.

htop inside a container

By default a container sees all host processes (if it does not have its own PID namespace). Inside a Docker container htop shows only its own processes. That is normal because of the [[namespaces|PID namespace]].

To see host processes from inside a container:

docker run --pid=host -it alpine sh -c 'apk add htop && htop'

When something looks wrong

• load 8 but CPU is idle. I/O wait. Processes are in state D, sleeping on disk. Check iostat -x 1 or the iowait color in htop.
• Memory looks nearly full but 200 MB shows free. Look at Available, not Free. Cache and buffers are returned to the kernel when needed.
• Process does not die even with SIGKILL. State D (uninterruptible). It is waiting on NFS, disk, or a kernel lock. Only a reboot or unblocking the device helps.
• htop itself appears at the top of the list. Go to F2 → Display and enable "Hide userland process threads" and "Hide kernel threads" to reduce htop's own CPU usage.
• Container names do not appear. Add the CGROUP column. The container name is in the path /sys/fs/cgroup/.../docker-XXXXX.

Alternatives

• top: always present, base utility.
• btop: graphs, ASCII art; slower on older CPUs.
• glances: network, disk, and processes in one window; written in Python.
• atop: background daemon with history; lets you examine a past load spike.