Read Linux Process Snapshots with ps Without Guessing

Type plain ps expecting every process on the box and you get a short, oddly narrow list instead. This guide uses ps to answer three practical questions: what is running, which process owns a PID, and what command line or resource data is worth investigating. The examples target procps-ng 4.0.4, installed here from the Ubuntu procps package. Allow about 10 minutes. You need a normal shell account; none of these checks needs elevated privileges.

Before you start

ps reports a snapshot: it reads process information once and exits, so it will not refresh itself. Use top or another monitor when you need repeated updates. The command reads /proc and needs no setuid or special permissions, so do not add any.

Check the version first:

ps --version

On the machine used for this guide, the result is:

ps from procps-ng 4.0.4

This implementation supports three option styles at once, and mixing them is where scripts go wrong:

• Unix options use a dash, such as -e.
• BSD options are grouped without a dash, such as ax.
• GNU long options use two dashes, such as --forest.

They can be mixed, but similar-looking commands can select different processes, so read the selection section below before putting one in a script.

Checkpoint 1: see the processes you started here

Run plain ps first:

ps

Its default selection is narrower than most people expect: processes with your effective user ID, attached to the same terminal as the invoking shell. The normal columns are PID, terminal, accumulated CPU time and executable name, and the output is not sorted by default.

For a wider view of your own processes across terminals, add BSD-style x, and only add a as well when you also want other users' processes. This first form is usually the safer personal overview:

ps x

BSD-style options change more than the display. They add process state, show command arguments, and include your processes on other terminals too, which is a common source of surprise when comparing the result with plain ps.

Checkpoint 2: inspect the whole machine

To select every process using the standard option spelling, run:

ps -ef

-e selects all processes and -f requests a full-format listing with command arguments. The exact rows depend on what is running, but you should see a header with fields such as UID, PID, PPID, TTY, TIME and CMD.

For a compact report with columns you choose yourself, use -o:

ps -eo pid,ppid,user,stat,etime,comm,args --sort=-%cpu

This asks for the process ID, parent ID, effective user, state, elapsed time, executable name and arguments, sorted by CPU percentage descending. Format names separate with commas or spaces. Redirecting output and need predictable width? Add something like --cols 160.

Use the report to find a PID, then narrow your next command to that process. A report is evidence for the next check, never a reason to kill or restart anything on its own.

Checkpoint 3: follow a parent and its children

To make parent-child relationships visible, request a forest view:

ps --forest -eo pid,ppid,stat,comm,args

The indentation and tree characters show the hierarchy. To inspect one known PID, swap in a real number from your output:

ps -p 1234 -o pid,ppid,stat,lstart,etime,comm,args

Replace 1234 before running the command. Expect one header and, if the PID exists, one matching row. An empty result is normal if the process exited between the earlier listing and this check, and a PID can also get reused later, so confirm the command and owner before you act on it.

Understanding state and command columns

STAT packs process state into a few characters. The first tells the main state:

• R running or runnable.
• S interruptible sleep.
• D usually uninterruptible I/O sleep.
• T stopped.
• Z a defunct zombie waiting for its parent to reap it.

Extra characters can describe properties such as a session leader, a multithreaded process or a foreground process group.

comm is the executable name. args is the command with its arguments, though arguments can be modified or unavailable. The command line can also contain secrets passed as arguments, so avoid pasting a full output into tickets, chat or public logs. -f normally includes arguments; use a format with only comm when you do not need them.

Finding processes by name or PID

Use -C to match an executable name, not its full command line:

ps -C sshd -o pid=,user=,stat=,comm=

The equals signs suppress column headings, handy for a script. A name match can return several rows, and that is not proof one particular service instance is the process you meant.

Use -p when you already have a PID, and -q for quick PID selection:

ps -q 1234 -o pid=,comm=,stat=

Quick mode reads the listed PIDs with no additional filtering. It preserves the PID order but does not allow sorting or forest output, which makes it useful for a small, known list and useless for discovery.

Common traps

• ps aux is not universal. This procps implementation accepts it as a compatibility case, mixing BSD and Unix conventions. The manual warns the strict interpretation asks for processes with a terminal plus processes owned by a user named x; if that user does not exist, ps falls back to the familiar BSD meaning. Use an explicit command such as ps -ef or ps ax when the selection actually matters.
• CPU and memory numbers are not live rates. The manual describes CPU percentage as usage over the process lifetime, and warns it may not total exactly 100 percent. RSS and virtual size also omit some kernel-backed memory. Treat these as clues for investigation, not a complete accounting system.
• Do not add sudo by reflex. Ordinary ps needs no elevated privilege. A root-only process may show less detail because of kernel or container restrictions, but granting ps special permissions is specifically discouraged. If a later action changes service state or kills a process, stop and verify the target, owner and recovery plan before reaching for a separate administrative command.

Done means

• You can explain what plain ps selects and why ps -ef is broader.
• You can inspect a known PID with a deliberate -o format.
• You can read the main STAT states and tell comm from args.
• You know ps is a snapshot, its output is unsorted unless requested, and its estimates need context.
• You have not used a process listing as permission to stop, kill or restart anything.