Module 06: Process Management

🎯 Goal: See what is running, understand its lifecycle, and stop or investigate a program without guessing.

By the end of this module, you should be able to identify a process and its PID, interpret basic process state and resource usage, send a graceful termination signal, distinguish a foreground job from a background job, and trace a listening server back to the process that owns it.

Why this matters

Every command you run, every server you start, and every script that hangs or misbehaves is a process — and eventually you will need to see what's running, figure out why something is eating CPU or won't respond, and stop it safely (or forcefully). This is exactly the skill you'll reach for later when a Docker container's process won't exit cleanly, or a Kubernetes pod is stuck, so building solid intuition here on plain Linux pays off directly in the later tracks.

Concepts

Start graceful; escalate deliberately

When a program is stuck, first identify it and ask it to exit with SIGTERM (the default kill signal). Use SIGKILL only when the process cannot respond: it gives the program no chance to flush data, remove temporary files, or release resources. The production habit is: observe → identify → terminate gracefully → verify → escalate only if necessary.

What a process is. A process is a running instance of a program. When you type htop and press Enter, the shell asks the kernel to load that program into memory and start executing it — that running instance is a process, with its own process ID.

PID and PPID. Every process gets a unique number called a PID (process ID) the moment it starts. Every process (except the very first one at boot) is started by some other process, called its parent, whose PID is recorded as the child's PPID (parent process ID). For example, when you run a command in your terminal, your shell (like bash) is the parent, and the command you launched is its child. This parent-child relationship forms a tree all the way back to the first process the kernel starts at boot.

PID 1 (init, the first process at boot)
  └── PID 842  bash (your login shell)          PPID=1
        ├── PID 1105  htop                       PPID=842
        └── PID 1201  sleep 300                  PPID=842
              (backgrounded with &, still a child of bash)

Every box in that tree traces back to PID 1 — this is why ps aux output has a PPID column at all, and why closing a parent shell (without nohup) tends to take its children down with it.

Foreground vs background. A foreground process has control of your terminal — your prompt won't come back until it finishes, and it can read your keyboard input directly. A background process runs without holding onto your terminal, so you get your prompt back immediately and can keep typing other commands while it runs.

Signals. A signal is a small, standardized message sent to a process asking it to do something — most commonly, to stop. SIGTERM ("terminate") politely asks a process to shut down, giving it a chance to clean up open files or save state before exiting; well-behaved programs honor this. SIGKILL is not a request — the kernel terminates the process immediately, with no chance for it to clean up anything. SIGKILL is a last resort for processes that ignore SIGTERM or are stuck (unresponsive).

Ctrl+C and Ctrl+Z from the keyboard. While a foreground process has your terminal, Ctrl+C sends it SIGINT (interrupt), which by default also ends the process — this is your everyday "stop this program" keystroke. Ctrl+Z is different: it sends SIGTSTP, which merely pauses (suspends) the process and hands your prompt back, without ending it — the paused process is still in memory, just not running, until you resume it.

  kill <PID>          SIGTERM (15)   "please stop" — process can catch it,
                                      clean up, and exit on its own terms

  kill -9 <PID>        SIGKILL (9)   "you're stopped" — kernel ends it
                                      instantly, no cleanup, can't be caught

  Ctrl+C                SIGINT (2)   "interrupt" — default action ends it,
                                      same idea as SIGTERM but from a keypress

  Ctrl+Z               SIGTSTP (20)  "pause" — process frozen in memory,
                                      resume later with fg/bg, not terminated

The escalation path for a stuck process is always: SIGTERM first (kill <PID>), give it a moment, only reach for SIGKILL (kill -9) if it truly won't respond.

Jobs: backgrounding and resuming from your shell. Your shell keeps track of processes you started from it as numbered "jobs." Appending & to a command starts it directly in the background. A process you Ctrl+Z-suspended, or backgrounded with &, can later be resumed in the foreground or background. This is entirely a convenience your interactive shell provides — it's tracking jobs launched in that shell session.

Surviving terminal closure with nohup. Normally, when you close your terminal, every process it started (including backgrounded ones) receives a hangup signal and typically dies. nohup ("no hangup") runs a command in a way that ignores that signal, so it keeps running even after you log out or close the terminal — useful for a long-running task you want to walk away from.

Command reference

Hands-on exercises

1. Open your WSL2 Ubuntu terminal. Run ps aux and look at the output. Find the line for your current shell (look for bash or similar in the command column near the end of the line), and note its PID.

2. Run ps aux | wc -l (a small pipe preview — it counts lines) to see roughly how many processes are currently running on your system.

3. Launch htop. Take a moment to look at the layout: CPU/memory bars at the top, and the scrollable process table below. Try pressing F6 (or your version's sort key) to sort by different columns, then press q to quit back to your prompt.

4. Start a long-running foreground command: sleep 60. Notice your prompt does not return — you're stuck waiting. Press Ctrl+C to interrupt it early, and confirm your prompt returns immediately with no "60 seconds" wait.

5. Start another sleep 300, and this time press Ctrl+Z instead of Ctrl+C. Your prompt should return, and the shell should print something like [1]+ Stopped sleep 300. Run jobs to confirm it's listed as Stopped. Then run bg %1 to resume it in the background, and jobs again to confirm its status changed to Running.

6. Start a background job directly with &: sleep 120 &. Note the [job-number] PID the shell prints. Run jobs and separately ps aux | grep sleep (previewing a pipe filter) to see the same process from two different views.

7. Bring that background job to the foreground: fg %1 (adjust the job number to match what jobs shows). Once it's in the foreground, press Ctrl+C to end it early instead of waiting out the full duration.

8. Find a process by name instead of by PID: start sleep 400 &, then run pgrep sleep to find its PID without scanning ps aux by eye. Kill it gracefully with kill <PID> (using the actual PID pgrep printed), and confirm it's gone by running pgrep sleep again (it should print nothing).

9. Break something on purpose: run kill 999999 (a PID that almost certainly doesn't exist on your system). Read the error message carefully — it should say "No such process," which tells you the PID was invalid, distinct from a permissions error. Then start sleep 500 &, find its real PID with pgrep sleep, and try kill -0 <PID> (signal 0 sends nothing but checks whether the process exists and you have permission to signal it) to confirm it's alive before finally killing it properly with kill <PID>.

10. Test nohup: run nohup sleep 120 &. Confirm a file named nohup.out appeared in your current directory (ls). Then run pgrep sleep to confirm it's running, and clean up with pkill sleep to stop it (and optionally rm nohup.out to tidy up the file it created).

Production practice: diagnose before killing

flowchart TD
    I["systemd (PID 1)"] --> S["myapp.service"]
    S --> P["myapp process"]
    P --> W["worker process"]
    S -. restart on failure .-> P

The tree explains who may restart a process. The response flow below explains how to intervene safely.

flowchart TD
    A["Unexpected process or port"] --> B["Inspect PID, owner, command"]
    B --> C{"Should it stop?"}
    C -->|No| D["Find parent / supervisor"]
    C -->|Yes| E["SIGTERM"] --> F{"Exited?"}
    F -->|Yes| G["Verify socket and logs"]
    F -->|No| H["Investigate; SIGKILL only if necessary"]

A focused incident loop

ps -fp <PID>              # identity, parent, and command
ps -o pid,ppid,user,stat,%cpu,%mem,command -p <PID>
ss -ltnp                  # listening TCP processes
lsof -p <PID>             # open files, when available
kill -TERM <PID>          # request a clean shutdown

Wait briefly and verify the result. If a process returns, inspect its parent, service manager, or container runtime rather than repeatedly killing it.

Independent challenge

No commands given here — figure it out yourself using what you know from this module and earlier ones.

Task: Start three separate background sleep processes with three clearly different durations. Without writing any PID down by hand as you launch them, later find and gracefully terminate only the longest-running one, leaving the other two alive and running. Then prove those two survivors are still there. If you'd like a live view of all three at once while you work, use the htop tool you installed back in module 05. Do the whole thing without copying the exact command sequence from the exercises above.

Common mistakes & troubleshooting

• Confusing Ctrl+C and Ctrl+Z: Ctrl+C ends the process; Ctrl+Z only pauses it (the process is still alive, just stopped, and will keep occupying resources like open ports until you fg/bg it or kill it). A "stopped" job left forgotten is a classic source of "why is this port still in use" confusion.
• Killing the wrong PID: PIDs are reused over time as processes come and go, so a PID you saw five minutes ago in ps aux output may belong to a completely different process now. Always re-check with a fresh ps aux, pgrep, or htop immediately before killing something specific.
• Reaching for kill -9 first: SIGKILL gives the process zero chance to clean up (e.g. flush a file it was writing, release a lock). Try plain kill (SIGTERM) first, and only escalate to -9 if the process ignores it and won't die.
• Forgetting a job is only tracked per shell session: jobs only shows jobs started in that terminal/shell session — closing the terminal (without nohup) or opening a new one means those job numbers are no longer visible or backgrounded there.
• Expecting killall/pkill to match exactly what you typed: these match by process name/pattern, which can unexpectedly hit more processes than intended if the name is generic (e.g. pkill python could kill several unrelated Python scripts at once). Double check with pgrep <pattern> first to see exactly what would be affected.
• Not redirecting nohup output and being surprised by a nohup.out file: if you don't redirect stdout/stderr yourself, nohup writes them into nohup.out in your current directory by default, which can pile up if forgotten.

Checkpoint quiz

Write down your answer to each question before expanding it — checking without attempting first is the single easiest way to fool yourself into thinking you've learned this.

1. What's the difference between a process's PID and its PPID?
2. Why does Ctrl+Z not actually end a running program, and what state is that program left in?
3. You run kill 4821 and nothing seems to happen — the process is still running a few seconds later. What signal did you just send, and what would be the next reasonable step?
4. Why is kill -9 considered a last resort rather than a first choice?
5. What's the practical difference between checking ps aux once versus running top/htop?
6. If you background a long task with sleep 600 & and then close your terminal, what generally happens to it, and what command would you have used instead to keep it running?
7. What's the difference between jobs and pgrep, given that both can tell you about running processes?
8. Why should you re-check a process's PID with a fresh ps aux or pgrep right before killing it, rather than trusting a PID you saw a few minutes earlier?

Further reading & sources

• man7.org: signal(7) - the full list of Unix signals (this module only covers the four you'll use daily) and how processes can catch or ignore them.
• man7.org: ps(1) - ps has dozens of output formats beyond aux; worth a skim once ps aux feels routine.
• htop explained (official site) - htop's own docs, covering the keyboard shortcuts and columns this module only lightly introduced.
• man7.org: nohup(1) - the nohup reference; also worth knowing disown and setsid exist as related tools for detaching processes from a shell.

Next

Continue to 07 - I/O Redirection and Pipes to learn how to control where a process's input and output actually go — the foundation for chaining commands together.