Starting and Stopping Programs on Purpose
Run something in the background, get your prompt back, and stop a process the right way — asking it to finish before forcing it. This is control, not luck.
I ran a long download and now my terminal is stuck waiting for it. And a different program froze — how do I kill it without pulling the plug?
Two everyday needs: run something without tying up your prompt, and stop something cleanly. Both are simple once you know the moves.
Into the background
Add & to the end of a command and it runs in the background: it starts, and your prompt comes straight back so you can keep working. jobs lists what you have backgrounded; fg brings one back to the foreground if you want to watch it again.
# a long job, run in the background — note the trailing &
$ ./backup.sh &
[1] 5573
# your prompt is back immediately; the job runs as PID 5573
$ jobs
[1]+ Running ./backup.sh &
# bring it back to the foreground to watch it, if you like
$ fg
./backup.sh -> runs and holds your terminal until it finishes
./backup.sh & -> runs in the background; prompt returns at once
Ctrl-C -> stop the program running in the FOREGROUND now
Ctrl-Z -> pause the foreground program; resume later with fg
- Line 3Ctrl-C is the everyday "stop this": it sends the gentle stop signalSignalA short message sent to a process to tell it something — most commonly, to stop. to whatever is running in front of you.
- Line 4Ctrl-Z only pauses — the program is frozen, not gone.
fgwakes it;bglets it continue in the background.
Stopping, gently then firmly
To stop a process by PIDPIDA process ID — the unique number the system gives each running process so you can refer to exactly one of them., kill sends it a signalSignalA short message sent to a process to tell it something — most commonly, to stop.. By default it sends the gentle one: "please shut down, save your work, tidy up". Only if that is ignored do you escalate to kill -9, the forceful one, which ends it instantly with no chance to clean up.
A text editor is frozen. Why try plain kill before kill -9?
kill asks the program to stop cleanly — a well-behaved editor will flush its buffer, save a recovery file, and exit tidily. kill -9 gives it no such chance: the process is terminated where it stands, and any unsaved work or half-written file is lost. Reach for the polite request first; use the sledgehammer only when the program refuses to listen.# find it
$ ps aux | grep frozen-app
wren 6120 ... frozen-app
# ask nicely first
$ kill 6120
# still there after a moment? then force it
$ kill -9 6120
When should you use `kill -9` (the forceful signal)?
kill -9 cannot be caught or ignored, which makes it reliable and also unforgiving: the process gets no chance to save or clean up. It is the right tool for a genuinely stuck program, but the wrong first move — a plain kill lets a healthy program exit gracefully, and that is almost always what you want.Your turn — take the box back
This machine has been compromised: something is quietly mining cryptocurrency and slowing everything down. Run ps aux to see every process, find the one that does not belong, and stop it with kill.
Force as a first resort
- kill -9 everything the instant it misbehaves
- Pulling the plug / hard reboot to end one stuck program
- Backgrounding jobs and losing course of what is still runningEscalating deliberately
- Ctrl-C or a plain kill first, so programs exit cleanly
- kill -9 only for the genuinely unresponsive
- jobs to keep course of what you have backgroundedControl of a system is knowing the gentle move and the forceful one, and choosing between them on purpose — not defaulting to force because it feels decisive.
Right — an ampersand to free my prompt, kill to stop cleanly, and kill -9 only if it will not listen.
That is control. You can now see what runs, start things without being trapped, and stop them the right way. That is a genuine working footing in the shell.
And a person who controls their processes deliberately is a person whose machine does what they expect — which, from my side, is the least fun kind to be up against.
Legal
Start and stop processes on your own machines freely. Killing or manipulating processes on a system you do not administer is interfering with it, and requires authorisation just as much as any other change.
So & frees your prompt, jobs/fg course and recall backgrounded work, and kill stops a process — gently first, forcefully only if it will not listen. That completes the free Linux course: you can converse with the shell, move through its one tree, make and read files, compose small tools with pipes, reason about permissions and privilege, and see and control what runs. Every paid course and hands-on lab stands on exactly this footing.