Loading...

VONDS ©

Lab 37: Investigating Processes with ps

Back to Lab Index

Investigate slowness by collecting process evidence using multiple ps views and filters. Produce targeted output for high-cost or suspicious processes and explain parent-child relationships with a tree view.

troubleshooting core services

Scenario

A developer reports that the host is running slowly. You need fast, CLI-only visibility into what is running, what is consuming resources, and whether a service-related process (like SSH) is behaving unexpectedly. Your job is to gather process evidence using multiple ps views and filters.

Operator context

This is first-pass triage. Collect evidence with ps before deeper tooling or per-service logs so you can justify what you suspect and why.

Objective

  • List all processes using a full-format listing.
  • Inspect only processes tied to the current terminal session.
  • Use BSD-style output to show CPU and memory columns.
  • Filter process output to isolate a specific daemon.
  • Generate a process tree view to understand hierarchy.

Concepts

  • Evidence-first triage: start broad, then narrow with filters.
  • Output styles: predictable columns (ps -ef) versus resource-focused columns (ps aux).
  • Session scope: plain ps commonly reflects the current TTY and helps confirm what your shell started.
  • Filtering: isolate a daemon, then verify PID, arguments, and ownership.
  • Hierarchy: parent-child relationships explain process families and aggregate load.

Walkthrough

Step 1 : Show all running processes (full format).
Command 
ps -ef

ps -ef gives a broad snapshot of what exists on the host. It includes PID and PPID so you can start reasoning about relationships and identify candidate parents for heavy process families. 

UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 Jul18 ?        00:00:05 /sbin/init
syslog     313     1  0 Jul18 ?        00:00:02 /usr/sbin/rsyslogd
user1     1783  1234  1 11:10 pts/0    00:00:00 top
Step 2 : Inspect processes attached to the current terminal.
Command 
ps

Plain ps commonly scopes to the current TTY. Use it when you need to confirm what your session launched and what is still running or blocked. 

PID TTY          TIME CMD
1783 pts/0    00:00:00 bash
1802 pts/0    00:00:00 ps
Step 3 : Use a resource-focused view (BSD style).
Command 
ps aux

ps aux includes CPU and memory columns and is a quick way to spot obvious offenders. Use it to find candidates, then switch to targeted inspection. 

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.1  22520  3364 ?        Ss   Jul18   0:05 /sbin/init
daemon     912  0.1  0.2  42636  4820 ?        Ss   11:05   0:00 /usr/sbin/cron
user1     1801  0.5  1.5 102344 15432 pts/0    S    11:15   0:02 ./build.sh
Step 4 : Isolate sshd-related processes.
Commands 
ps aux | grep sshd
# OR
ps -ef | grep sshd

Filtering lets you isolate service daemons and per-user sessions quickly. Confirm expected users and arguments, then look for unexpected sessions or runaway children. 

root      1437     1  0 Jul18 ?        00:00:06 /usr/sbin/sshd -D
user1     1805  1437  0 11:16 ?        00:00:00 sshd: user1@pts/0
Step 5 : Produce a process tree view.
Commands 
ps -ejH
# OR
ps f

Tree views help you explain relationships. The slow host story is often a process family, not a single PID. Use a hierarchy view to identify the parent and enumerate children. 

PID  PGID   SID TTY      TPGID STAT   UID   TIME COMMAND
  1     1     1 ?           -1 Ss       0   0:05 /sbin/init
 91    91    91 ?           -1 Ss       0   0:00  \_ /lib/systemd/systemd-journald
1437  1437  1437 ?           -1 Ss       0   0:06  \_ /usr/sbin/sshd -D
1805  1805  1805 pts/0    1805 Ss    1000   0:00      \_ sshd: user1@pts/0

Common breakpoints

ps output is too large

Narrow scope. Start with ps -ef, then filter for a service name, user, or PID. Do not attempt to reason about the full listing during an incident.

grep matches grep

Filtering output often includes the grep command line itself. Treat that match as noise and focus on the long-lived daemon and its children.

No obvious single offender

Use a tree view to find process families. Aggregate load can be high when many small children exist under one parent.

sshd appears multiple times

This may be normal: one master daemon with per-session children. Validate the expected users and TTYs, then look for unexpected sessions or arguments.

Cleanup checklist

This lab is read-only and does not change system state. Cleanup is saving output so you can compare against a known-good snapshot and support escalation with evidence.

Commands 
ps -ef
ps aux
ps aux | grep sshd
ps -ejH
Success signal

You can name the top processes, explain what they are doing, and describe parent-child relationships for any suspicious process family.

Reference

  • ps : Displays a snapshot of processes (defaults vary; commonly current TTY/session).
  • ps -ef : Full-format process listing (SysV style) showing PID, PPID, start time, and the full command line.
    • -e : Selects all processes.
    • -f : Full format (adds UID, PID, PPID, start time, TTY, and full CMD columns).
  • ps aux : BSD-style listing with CPU and memory columns for quick resource triage.
    • a : Shows processes for all users (not just the current user).
    • u : User-oriented format (adds USER, %CPU, %MEM, and related columns).
    • x : Includes processes without a controlling TTY.
  • grep <pattern> : Filters lines matching a pattern (commonly used to narrow process output).
    • <pattern> : String or regex to match (for example sshd).
  • ps -ejH : Full listing with job/session fields and hierarchy displayed using indentation.
    • -e : Selects all processes.
    • -j : Job format (includes PGID and SID fields useful for session reasoning).
    • -H : Displays process hierarchy using indentation.
  • ps f : ASCII “forest” view of process hierarchy.
    • f : Forest view (tree-like output in the listing).