Read Linux Process Snapshots with ps Without Guessing

You will use 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 for the walkthrough. You need a normal shell account; none of these checks needs elevated privileges.

Before you start

ps reports a snapshot. It reads process information and exits, so it will not refresh by itself. Use top or another monitor when you need repeated updates. The command reads /proc and does not need setuid or special permissions. Do not add special permissions to it.

Check the version first:

ps --version

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

ps from procps-ng 4.0.4

Options in this implementation come in three styles. 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 many people expect. It shows processes with your effective user ID that are attached to the same terminal as the invoking shell. The normal columns are the PID, terminal, accumulated CPU time and executable name. The output is not sorted by default.

For a more useful view of your own processes across terminals, use BSD-style x together with a only when you also want processes owned by other users. 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. The extra selection is a common source of surprise when comparing ps with plain ps.

Checkpoint 2: inspect the whole machine

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

ps -ef

The -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 containing fields such as UID, PID, PPID, TTY, TIME and CMD.

For a compact report with columns chosen by you, 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, then sorts by CPU percentage in descending order. Format names are separated by commas or spaces. If you redirect output and need predictable width, add a width such as --cols 160.

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

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, replace the example with a real number from your output:

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

Expected output has one header and, if PID 1234 exists, one matching row. Replace 1234 before running the command. If the process exits between the first listing and this check, an empty result is normal. A PID can also be reused later, so confirm the command and owner before taking any action.

Understanding state and command columns

STAT is a compact process state. The first character is the main state: R means running or runnable, S means interruptible sleep, D usually means uninterruptible I/O sleep, T means stopped, and Z means a defunct zombie waiting for its parent to reap it. Additional 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, although arguments can be modified or unavailable. The command line can contain secrets supplied as arguments, so avoid pasting complete output into tickets, chat or public logs. The -f option normally includes arguments; use a format containing 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, which makes the result convenient for a script. A name match can return several rows. It is not proof that one particular service instance is the process you meant.

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

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

Quick mode reads the listed PIDs without applying additional filtering. It preserves the PID order, but does not allow sorting or forest output. That makes it useful for a small, known list, not for discovering processes.

Common traps

Do not treat ps aux as a universal spelling. This procps implementation accepts it as a compatibility case, but it mixes BSD and Unix conventions. The manual warns that the strict interpretation asks for processes with a terminal plus processes owned by a user named x; if that user does not exist, ps assumes the familiar BSD meaning. Use an explicit command such as ps -ef or ps ax when the selection matters.

Do not assume the biggest CPU or memory value is a current rate. The manual describes CPU percentage as usage over the process lifetime, and it warns that it may not total exactly 100 percent. RSS and virtual size also omit some kernel-backed memory. Treat these fields as clues for investigation, not as a complete accounting system.

Do not add sudo automatically. Ordinary ps needs no elevated privilege. A root-only process may expose less detail because of kernel or container restrictions, but granting special permissions to ps is specifically discouraged. If a later action changes service state or terminates a process, stop and verify the target, owner and recovery plan before using 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 distinguish comm from args.
• You know that 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.