Step 26. Process Management — List Them, Find Them, Signal Them

Level 0 — Understanding Computer Operation and Structure | Difficulty ★★☆☆☆ | Estimated time: 3 hours

Prerequisites: You must be able to use the basic Linux commands from Steps 18–21. You need an Ubuntu VM (or WSL Ubuntu).

What you need: An Ubuntu terminal. Nothing new to install.
Caution: Most of today’s practice is listing things, but kill, which terminates processes, does appear. Use it only on the test process (sleep) that we create ourselves. Firing kill at some other process ID can destroy work in progress or freeze the system.

Right now, dozens of programs are running simultaneously inside your Ubuntu. The one managing the network, the one recording logs, the one that put up your terminal — each is a living unit of execution, a process. When a server acts strange, the first thing an administrator does is look at "what’s running right now?" and the first page of any incident investigation is "capture the process list." Today you’ll learn to list processes, create them, find them, and end them.

1. Learning Objectives

By the end of this chapter, you will be able to:

View the list of running processes and find each one’s PID (number) and PPID (parent’s number)
Move jobs between foreground and background with &, jobs, fg, and bg
Explain that kill is not "killing" but "sending a signal"
State the difference between SIGTERM (15) and SIGKILL (9) and the correct order of use
Find CPU-hungry processes in real time with top

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language & environment	bash — Ubuntu terminal (VM or WSL)
Today’s commands	`ps aux` (full list), `ps -ef` (includes parent PID), `jobs`/`bg`/`fg` (move between jobs), `kill [PID]` (send a signal), `top` (real-time monitoring)
Concepts needed	PID and PPID, signals (SIGTERM, SIGKILL, SIGINT), foreground vs. background, daemons

2-1. PID and PPID — A Process’s Number Ticket and Family Tree

Every process gets a unique number when it’s born. That’s the PID (Process ID). It also records the PPID (Parent PID) — the number of "the parent process that launched me." In Step 13 you traced process family trees in Windows. The same concept exists in Linux.

This genealogy matters in security for the same reason: normal programs are born from predictable parents, while malware is often born from strange ones.

2-2. Signals — Messages You Send to Processes

In Linux, the way you talk to a running process is a signal. It’s a system for delivering intent, like ringing a doorbell. The main ones:

Signal	Number	Meaning
SIGTERM	15	"Please clean up and exit" — a polite termination request. kill’s default
SIGKILL	9	"Vanish immediately" — cannot be refused, no chance to clean up
SIGINT	2	The signal sent when you press Ctrl+C (interrupt)
SIGHUP	1	"Terminal disconnected" — by convention, daemons reload their config when they receive this

The name kill is misleading. kill is not a "killing command" but a command that sends signals. It’s just that the default signal is a termination request (SIGTERM), so it mostly gets used for killing.

2-3. Why -9 Is the Last Resort

A process that receives SIGTERM decides "time to go" and cleans up after itself: closing open files, saving what needs saving, tidying network connections. SIGKILL (-9), on the other hand, has the kernel annihilate the process on the spot. With no chance to clean up, unsaved data is lost and temporary files are left scattered.

So the order is always fixed: ① plain kill (SIGTERM) → ② wait a moment and check → ③ only if it still won’t listen, kill -9. Reaching for kill -9 as the first option is the mark of a beginner in the field.

2-4. Foreground and Background

When you type a command in the terminal, the prompt usually doesn’t come back until that command finishes. That’s foreground execution. Append & to the command and it runs behind the scenes while the prompt returns immediately. That’s background execution.

To push something already running in front to the back, press Ctrl+Z (pause) then bg; to call it back to the front, use fg. And jobs shows the roster of jobs moving around in this terminal.

2-5. Daemons — Quiet Resident Workers

A daemon is a process that lives in the background and works without a screen. Web servers, log collectors, time synchronizers — things like that. There’s a convention of ending their names with d, like sshd, cron, and syslogd. They occupy the same place as Windows "services" (Steps 5, 13).

3. Follow Along

3-1. What’s Running Right Now — ps aux

ps aux | head -12

USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1 12.1  0.1  21740 13188 ?        Ss   11:28   0:00 /sbin/init
root           2  0.0  0.0   3180  2204 hvc0     Sl+  11:28   0:00 /init
root           6  0.0  0.0   3604  2412 hvc0     Sl+  11:28   0:00 plan9 --control-socket 7 ...
root          49  3.7  0.1  33916 12648 ?        S<s  11:28   0:00 /usr/lib/systemd/systemd-journald
root          98  3.2  0.0  25148  6488 ?        Ss   11:28   0:00 /usr/lib/systemd/systemd-udevd
systemd+     114  2.0  0.1  21468 13284 ?        Ss   11:28   0:00 /usr/lib/systemd/systemd-resolved
...

(Verified 2026-09-09 on WSL Ubuntu 24.04. Your VM’s list, numbers, and usernames will differ — seeing your own username in the USER column is normal.)

How to read the output: Interpret the columns. USER is the process’s owner, PID is its number ticket, %CPU and %MEM are resource usage, STAT is the state (S=sleeping, R=running, Z=zombie), and COMMAND is the command that was run. See process number 1 at the top? It’s the ancestor of all processes. The options mean: a = all users, u = detailed, x = include even those without a terminal.

Why: The first step of any system check is always "view the list." Being able to read this table comfortably is today’s first harvest.

3-2. Seeing the Parent’s Number Too — ps -ef

ps aux doesn’t show the parent’s number. To see parents, change the format:

ps -ef | head -10

UID          PID    PPID  C STIME TTY          TIME CMD
root           1       0 12 11:28 ?        00:00:00 /sbin/init
root           2       1  0 11:28 hvc0     00:00:00 /init
root           6       2  0 11:28 hvc0     00:00:00 plan9 --control-socket 7 ...
root          49       1  3 11:28 ?        00:00:00 /usr/lib/systemd/systemd-journald
root          98       1  3 11:28 ?        00:00:00 /usr/lib/systemd/systemd-udevd
systemd+     114       1  2 11:28 ?        00:00:00 /usr/lib/systemd/systemd-resolved
...

(Verified 2026-09-09.)

How to read the output: The third column is the PPID — the number of the process that launched me. Let’s read the family tree from this live table. PID 1’s PPID is 0 (nothing above it — meaning it’s the primordial ancestor). journald (49) has PPID 1, meaning process 1 launched it directly. The udev-workers’ PPID is 98 — systemd-udevd, right above them. "Who launched whom" is proven by numbers, not guesswork.

3-3. Creating a Test Process — Background Execution

Now let’s make a process ourselves. sleep, the "do nothing for N seconds" command, is a perfect fake job for experiments:

sleep 300 &

[1] 652

(Sample output — the format matches the live capture. [1] is the job number; the number after it is this process’s PID. The numbers on your screen will differ.)

The & at the end means "run this in the background." The prompt came right back, right? Let’s view this terminal’s job roster:

jobs

[1]+  Running                 sleep 300 &

(Verified 2026-09-09 — the live check used sleep 5, and the format is identical.)

Why: A single & lets you run a program without tying up the terminal. Sending long tasks to the back while you keep doing other things is a fundamental skill.

3-4. Finding and Terminating — ps + grep + kill

Find the process you made in the system-wide list:

ps aux | grep sleep

root         652  0.0  0.0   3132  1904 pts/0    S+   11:28   0:00 sleep 300
root         660  0.0  0.0   4096  2088 pts/0    S+   11:29   0:00 grep sleep

(The second line is the form verified live on 2026-09-09.)

How to read the output: Two lines appear. The first is the real sleep; the second line is the grep you just typed itself — a famous trap that trips up beginners, because the search term appears in its own command line, so it catches itself. Attach grep -v grep ("exclude lines containing grep") like ps aux | grep sleep | grep -v grep to filter yourself out. It’s a staple combination in every practitioner’s muscle memory.

⚠️ Caution — use kill carefully: Here comes the command that terminates processes. Before running it, make sure the number after kill is the PID of the test sleep you just identified. If you mistype the number and terminate some other process, that program’s unsaved work could be lost.

kill 652
jobs

[1]+  Terminated              sleep 300

(Sample output — the format matches real behavior. Replace 652 with the PID you confirmed.)

How to read it: The sleep that received the default signal (SIGTERM) exited obediently. "Terminated" means it cleaned up and left.

Why: "List (ps) → find the number (grep) → send a signal (kill)" — this three-step combo is the basic move of process management.

3-5. Forced Termination and a Safety Check — kill -9, and a Nonexistent Number

This time, let’s see what forced termination looks like:

sleep 600 &
kill -9 655
jobs

[1]+  Killed                  sleep 600

(Sample output — same format as real behavior. Replace the PID with yours.)

How to read it: The message isn’t "Terminated" — it’s "Killed". It died instantly, with no cleanup. This difference is the "last resort" instinct from section 2-3.

Make a prediction: What if you mistype a PID and fire kill at a nonexistent number, like kill 99999? ① Nothing happens ② An error message ③ The computer shuts down. Predict, then check. (Answer: ② — the live result shows the error bash: kill: (99999) - No such process. kill is a command to use carefully, but a nonexistent number is simply refused. Verified 2026-09-09.)

3-6. Real-Time Observation — top

top

The whole screen turns into a real-time table, with numbers moving every few seconds. The top part of the live screen:

top - 11:29:11 up 0 min,  1 user,  load average: 0.00, 0.00, 0.00
Tasks:  30 total,   1 running,  29 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   7655.7 total,   6382.1 free,    597.3 used,    827.9 buff/cache

(Verified 2026-09-09 — captured in batch output mode. On your screen, the numbers keep moving.)

How to read it: The upper part summarizes CPU and memory; the lower part is the process ranking sorted by %CPU. You can see at a glance which process is working hard. Press q to quit.

Why: It’s the standard first tool for the question "the server is slow — what’s eating it?"

4. Missions & Exercises

Mission — Build a Process Management Three-Step Card

Run sleep 500 & three times to create three test processes
Confirm all three appear in jobs, and find them in the system list too with ps aux | grep sleep | grep -v grep
Clean up one with plain kill and another with kill -9, and record the difference between the messages (Terminated / Killed)
From ps -ef | head -20, find three processes whose PPID is 1 and write them down on paper
Clean up the last one and confirm jobs is empty, then write up in signals.txt when to use each of today’s three signals (15, 9, 2)

Exercises

Question 1. Why is it more accurate to describe kill as "a command that sends signals" rather than "a command that kills"? What signal goes by default?

Question 2. Explain the difference between SIGTERM and SIGKILL from the perspective of "cleanup," and say why you should always try SIGTERM first.

Question 3. You ran ps aux | grep sleep and got two lines. What is the second line, and how do you filter it out?

Question 4. You closed the terminal and the background job you’d launched with & died along with it. Which signal caused that, and what should you do for jobs that need to run for a long time?

5. Model Answers & Completion Criteria

Mission Model Answer

sleep 500 &
sleep 500 &
sleep 500 &
jobs
ps aux | grep sleep | grep -v grep
kill <firstPID>          # → Terminated
kill -9 <secondPID>      # → Killed
ps -ef | head -20        # find three processes with PPID 1
kill <thirdPID>
jobs                     # complete when it's empty

How to verify: ① Did all three jobs appear in the jobs output? ② Were the two termination messages different — Terminated vs. Killed? If so, you’ve confirmed the difference between the two signals with your own eyes. ③ Is the final jobs empty? Anything left is a missed cleanup. ④ Representative processes with PPID 1 in the live environment are the systemd family — systemd-journald (49), systemd-udevd (98), systemd-resolved (114): the system workers raised directly by process 1.

Exercise Solutions

Question 1 solution. Because kill’s original function is delivering signals to a process (you can see the full list of sendable signals with kill -l — verified live on 2026-09-09, from 1 SIGHUP through 15 SIGTERM), and termination is just one of its uses. The default signal is SIGTERM (15).

Question 2 solution. SIGTERM "requests" termination from the process, giving it time to clean up — closing open files, saving data, and so on. SIGKILL has the kernel annihilate the process immediately, with no chance to clean up. So you always send SIGTERM first and use SIGKILL only when there’s no response — it’s the order that protects data.

Question 3 solution. The second line is the grep command you just ran itself. Since the search term ("sleep") appears in its own command line, it catches itself in the process list. Filter it out with ps aux | grep sleep | grep -v grep.

Question 4 solution. When the terminal closes, its child processes receive SIGHUP (hangup), and the default behavior on receiving it is to exit. For long-running jobs that must survive a closed terminal, use tools like nohup or tmux — for now, just remembering that they exist is enough.

Completion Criteria Checklist

[ ] I can explain what PID and PPID mean
[ ] I can read the main columns of ps aux output (USER, PID, %CPU, STAT, COMMAND)
[ ] I can explain that kill is a command that sends signals
[ ] I can state the difference between SIGTERM and SIGKILL and the order to use them
[ ] I can create and check background jobs with & and jobs
[ ] I know the trap of grep catching itself and the grep -v grep fix
[ ] Mission: I completed the three-step card and signals.txt

6. Common Pitfalls & Fixes

Wall 1. "I ran kill but it won’t die"

Symptom: Even after kill, the process still shows up in ps.
Cause: Either it’s a program built to ignore SIGTERM, or its cleanup work is long and it’s in the middle of dying.
Fix: Wait a few seconds and check again. If it’s still alive, that’s when you use kill -9. The habit of reaching for -9 from the start causes data loss.

Wall 2. "grep gives me two matches for what I’m looking for"

Symptom: ps aux | grep something shows the real process and grep itself together (reproduced and verified live on 2026-09-09).
Cause: The grep command line also contains the search term, so it matches itself.
Fix: Append | grep -v grep to exclude yourself.

Wall 3. "I closed the terminal and my background job died"

Symptom: A job launched with & disappears when the terminal closes.
Cause: When the terminal closes, its child processes receive SIGHUP ("hangup"). The default behavior is to exit.
Fix: For now, it’s enough to understand that "background jobs share the terminal’s fate." Just remember that jobs meant to run long on a server use tmux or nohup.

Wall 4. "I can’t kill someone else’s process"

Symptom: You run kill and get Operation not permitted.
Cause: Processes have owners too. You can’t touch other people’s processes — an extension of permissions (Steps 23–24).
Fix: That’s not an error; it’s correct behavior. If you need to clean up a system process, you need sudo — and before that, you need to ask "am I allowed to kill this?"

Wall 5. "It’s in jobs but not in ps aux (or vice versa)"

Symptom: The two commands give different results.
Cause: jobs only sees "jobs started in this terminal right now," while ps aux sees the entire system. They’re tools with different scopes.
Fix: Use jobs for things you just launched with &, and ps when hunting a process somewhere in the system. Keep the purposes separate and you won’t get confused.

7. Summary

Today’s Concepts

Concept	One-line description
PID / PPID	A process’s unique number / the number of the parent that launched it
Signal	A messaging system for delivering intent to processes
SIGTERM (15)	A polite termination request — cleanup possible, kill’s default
SIGKILL (9)	Instant annihilation — cannot be refused, the last resort
Foreground / background	Holding the prompt while running / running behind the scenes (`&`)
Daemon	A background worker with no screen that stays resident (names end in d by convention)

Today’s Commands

Command	What it does
`ps aux`	Full process list (with resource usage)
`ps -ef`	List that includes parent numbers (PPID)
`command &`	Run in the background
`jobs` / `fg` / `bg`	This terminal’s job roster / bring to front / send to back
`kill [PID]`	Send a signal (default SIGTERM) ⚠️ always confirm the target
`kill -9 [PID]`	Force-annihilate (SIGKILL) ⚠️ last resort
`top`	Real-time process monitoring (quit with `q`)
`kill -l`	Full list of sendable signals

The Instinct That Matters More Than Commands

In the field, "the server is dead" almost never means "the computer turned off" — it means "some process isn’t responding." At that moment, beginners think of rebooting first; veterans open ps and top first. Which process is eating all the CPU? Is the unresponsive service’s PID still alive? The list tells you. Rebooting is equivalent to "SIGKILLing every process," which makes it the final card — one that kicks away your own chance to find the root cause.

And one more perspective: see process management not as "killing" but as "having a conversation," and the commands look different. kill isn’t a threat; it’s a doorbell. Ring politely (SIGTERM), and break the door down (SIGKILL) only when there’s no answer — that order is the courtesy that protects data.

Remember two more things. First, process 1 is the ancestor of all processes, and on modern Ubuntu, systemd holds that seat — the "king of the process world," managing the start, monitoring, and restart of system services (daemons). The PPID 1 children you saw in today’s ps -ef are the proof. Second, the common first page of any incident response manual is "capture the process list" — are there names that weren’t there before, do any have strange parents, is there a fake imitating a system name (like svch0st)? Today’s ps and genealogy reading are how you ask those questions, and today’s three-step combo is the primitive form of that investigation.

Being able to handle processes means being able to read the computer’s "right now." If files are records of the past, processes are the breath of the present. Learning how to watch before learning how to kill — that is today’s real harvest.

Once every box is checked, Step 26 is complete. Click the checkbox in the sidebar to save your progress.