Gather useful evidence about CPU, memory, filesystems and processes before deciding whether a running workload needs intervention.

Series: Previous: permissions · Part 4 of 6 · Next: networking
Applies to: Linux, procps-ng, GNU Coreutils and psmisc; htop is optional. Resource figures and process IDs below are illustrative, not measurements of a production host.

The subsystem: processes, memory and mounted storage

A process is a running program with an identity, address space and kernel-managed resources. The scheduler shares CPU time among runnable tasks. Memory management uses RAM for processes and caches, with swap potentially supporting some memory pages. Filesystems account for storage separately from process memory.

Many monitoring tools read /proc or other kernel interfaces. A snapshot answers “what is visible here now?” Container namespaces, cgroup limits and permissions can restrict that view. A container’s output does not necessarily describe the physical host or its workload limits.

During an enterprise incident, gather a short baseline, compare it with normal behavior and identify the affected workload. Avoid restarting a service merely because one number looks large.

top and htop: interactive process inspection

top
htop

Both display an updating process view; htop is a separate optional package. Quit with q. Look at the process consuming resources, the overall CPU mix and whether behavior persists across refreshes. A process above 100% CPU can reflect multiple threads using multiple logical CPUs; it is not automatically a reporting error.

For one non-interactive procps-ng sample:

top -b -n 1

The first sample has timing limitations and is not a substitute for a sustained measurement. Do not install htop on a production host merely to follow the tutorial; existing read-only tools may be enough.

ps: capture a process snapshot

ps -eo pid,ppid,user,stat,pcpu,pmem,comm --sort=-pcpu

This names the fields explicitly and sorts by reported CPU percentage. For procps-ng, %CPU reflects CPU time relative to elapsed process lifetime, not an instantaneous measurement. ps aux is also common, but full argument strings can expose tokens or other internal data. Use comm when command names are sufficient; inspect arguments only when needed and authorized.

kill: send a signal to an identified process

kill sends signals; it does not promise that a process will immediately disappear. The default signal is TERM, which a program may handle gracefully. KILL cannot be caught and prevents application cleanup.

This example targets only a disposable process created by the current shell:

sleep 60 &
lab_pid=$!
kill -TERM "$lab_pid"
wait "$lab_pid" || :

Confirm a real workload’s identity and approved shutdown procedure before signalling it. Prefer a service’s supported management interface when a supervisor would immediately restart the process. Even kill -0 PID is only a momentary existence/permission check; PIDs can be reused.

killall: understand the wider name-based scope

On Linux with psmisc, this preview lists processes with an exact command name:

pgrep -a -x lab-worker

A separately authorized termination might use killall -TERM -- lab-worker. That can signal multiple matching processes, so it is unsuitable when you intend to stop only one instance. Do not try it against a common shared-service name as an exercise. killall has different semantics on some non-Linux systems; this chapter assumes Linux psmisc.

free: read memory availability

free -h

Focus on the available estimate along with workload behavior, rather than treating all cache as unavailable RAM. Linux uses otherwise idle memory for caching and can reclaim much of it. Low available memory and sustained swap activity can justify further investigation, but this one snapshot does not prove memory pressure or identify a leaking process.

df: inspect filesystem capacity

df -h -- .
df -i -- .

The first reports space for the filesystem containing the current directory. The second reports inode usage where supported. A filesystem can run out of inodes even when byte capacity remains. A read-only mount, quota or reserved capacity can also explain a failed write; “there is space in df” is not a complete diagnosis.

du: estimate storage used by a tree

du -sh -- "$HOME"

This summarizes allocated disk usage under an authorized directory. A large home tree can take time to scan; use an exact application subdirectory when possible. du and df measure different things. Deleted-but-open files can consume filesystem space without appearing in a directory walk, and sparse files can have a large apparent size with fewer allocated blocks.

uname: identify the kernel context

uname -srmo

This reports the kernel name, release, architecture and operating-system label where supported. It does not reliably identify the distribution release; read /etc/os-release for that context. Inside a container, the kernel is normally shared with the host while the user-space distribution may differ.

uptime: place the snapshot in context

uptime

The output includes uptime and one-, five- and fifteen-minute load averages. Linux load includes runnable tasks and tasks in uninterruptible sleep; it is not simply a CPU utilization percentage. Compare it with CPU count, storage behavior and a baseline. A recently booted host may also be warming caches or recovering workloads.

Practical script: a bounded triage snapshot

Save as triage-snapshot.sh; run bash triage-snapshot.sh /path/to/approved/application-directory. The script prints observations and sends no signals. It creates a private temporary file for the process snapshot and reports its path; no cleanup is automatic.

#!/usr/bin/env bash
set -euo pipefail
export LC_ALL=C
umask 077
if (( $# != 1 )) || [[ ! -d $1 || ! -r $1 || ! -x $1 ]]; then
  printf 'Usage: bash triage-snapshot.sh READABLE_DIRECTORY\n' >&2
  exit 2
fi
target=$1
printf 'Kernel:\n'; uname -srmo
printf '\nUptime:\n'; uptime
printf '\nMemory:\n'; free -h
printf '\nFilesystem capacity:\n'; df -h -- "$target"
printf '\nFilesystem inodes:\n'; df -i -- "$target"
printf '\nDirectory usage (may take time on a large tree):\n'
du -sxh -- "$target"
process_report=$(mktemp)
ps -eo pid,ppid,user,stat,pcpu,pmem,comm --sort=-pcpu > "$process_report"
printf '\nFirst ten process rows plus header:\n'
head -n 11 -- "$process_report"
printf '\nFull process snapshot retained at: %s\n' "$process_report"

GNU du -x stays on the same filesystem, although a large directory can still make the scan expensive. The output supports triage, not an automated health verdict. If a command fails, the script stops rather than silently issuing a complete-looking report. Review captured process names and paths before sharing them.

References

procps-ng project, top manual, ps manual, free manual, Linux signals, htop documentation, GNU disk usage.

FILED UNDER