Hack University - Processes: ps, kill, and the background

Programs become processes

The day this lesson matters: a program freezes your terminal, or something on a server is stuck eating 100% CPU, or a port is "already in use" and you need to find the program holding it. Process tools let you see and stop running programs without rebooting the machine.

A process is a running program. Open three terminals and run bash in each: one program, three processes. The OS gives every process a PID (process ID number).

The inspection tools:

ps: list your processes. ps aux lists everything running on the machine, one process per line (great for piping into grep).
kill PID: politely ask a process to quit (it sends a signal named TERM).
kill -9 PID: force-quit, no questions (signal KILL). Last resort.

And the keyboard shortcuts you'll use daily in a real terminal: Ctrl+C stops the program currently hogging your prompt, and Ctrl+Z pauses it and drops it into the background.

Foreground and background

Normally the shell waits for each command to finish before giving you the prompt back: the command runs in the foreground. End a command with & and it runs in the background instead, so you keep working while it churns:

sleep 60 &

The shell tracks these as jobs: jobs lists them, fg brings one back to the foreground, and wait pauses the script until background jobs finish. Inside a script, the special variable $! holds the PID of the most recent background job, which is exactly what you need to kill it later.

Two timelines comparing foreground and background execution. In the foreground case a single line shows sleep occupying the whole second before echo can run, so the prompt is blocked. In the background case, added by a trailing ampersand, sleep occupies its own timeline while echo runs immediately on a second timeline below, and wait is what rejoins the two.

Sending a command to the background with &

sleep runs in the background thanks to the trailing &, the echo proves the shell did not wait for it, and wait then blocks until the job finishes.

sleep 1 &
echo "the shell is free while sleep runs"
wait
echo "background job finished"

Output

the shell is free while sleep runs
background job finished

The order of those two lines is the whole demonstration. The first echo printed immediately, while sleep was still counting, which is only possible because & handed the shell back its prompt. Without the &, the first line would appear a full second later, after sleep had run to completion.

Stopping a background job by its PID

A thirty-second sleep starts in the background, $! remembers its PID, and kill ends it immediately, so the whole sequence finishes in well under a second instead of waiting half a minute.

sleep 30 &
pid=$!
kill $pid
wait $pid 2>/dev/null
echo "stopped the long sleep early"

Output

stopped the long sleep early

$! is the key piece: it holds the PID of the most recent background job, saved here into a variable named pid, and variables are what unit 7 opens with. The 2>/dev/null on the wait line discards the notice the shell would otherwise print about the terminated job, using the stderr redirection from lesson 5-1.

To stop a script that is running in your terminal immediately, press Ctrl+C. It interrupts the foreground process and returns you to the prompt.

The near neighbors do something different, and the distinction matters. Ctrl+Z only pauses the program and keeps it around as a suspended job, which catches people out when a supposedly stopped program is still holding a file or a network port. And q is not a general stop key at all: it quits pagers such as less and man, and nothing else.

Hunting down a runaway process

A stuck program called musicd is eating the CPU on a machine, and this session tracks it down and stops it. Each command is shown with the output it produced.

The first step is finding the process, by piping the full process list through grep so only the interesting line survives:

$ ps aux | grep musicd
sam   4217  98.3  1.2  musicd

That line gives both the evidence and the target: 98.3 is the percentage of CPU it is consuming, and 4217 is its PID. A plain kill asks it politely to shut down:

$ kill 4217

Some programs ignore that request, and this one is still running afterwards. Signal 9 is the escalation, which the kernel enforces without giving the program any say:

$ kill -9 4217
[1]+  Killed    musicd

The Killed notice is the shell confirming the process is gone. Working in that order, polite request first and -9 only if needed, gives a well-behaved program the chance to clean up after itself before it exits.

ps aux lists every process on the machine along with its user, PID, and resource usage, which is what makes it the starting point for any process hunt. The flags are a classic three-letter combination: a for all users' processes, u for the user-oriented detail columns, and x to include processes not attached to a terminal.

Because the output is one process per line, it pipes naturally into the tools from unit 5. The everyday move is ps aux | grep firefox to isolate one program's line and read its PID, then kill that PID.