Ctrl-Z and SIGTSTP

ctrl-z - a hands-on Linux lab on a real virtual machine.

Freeze a running foreground job with the Ctrl-Z keystroke, which sends SIGTSTP and leaves the job Stopped, not killed. Stopped means frozen and resumable with fg or bg, and jobs proves it is still in the table. Contrast with Ctrl-C (SIGINT, kills) and Ctrl-\ (SIGQUIT). Ctrl-Z is a keystroke, so the drills teach the commands around it; your job number and PID vary.

You start a command that takes a while. A long copy, a slow download, a sleep that will not return for a minute and a half. It sits there in the foreground, holding the terminal hostage. Your cursor is gone. You cannot type another thing until it finishes.

You do not want to kill it and lose its progress. You just want your prompt back for a moment, then to pick the job up again where it left off. There is a single keystroke that does exactly that: it freezes the running job in place and hands you a fresh prompt. The keystroke is Ctrl-Z, and this lesson is about the pause button of the shell.

The black boxes in this lesson are a practice terminal: a safe sandbox that checks the one command each step teaches. One honest catch, unique to this lesson: Ctrl-Z is a keystroke, not something you type, so you cannot enter it into an answer box and no drill grades on Ctrl-Z itself. You will practice the real commands that go AROUND the keystroke: starting a foreground job and reading the job table afterward. The frozen-job line the keystroke prints is shown as an example, and its job number and process ID will read differently on your machine.

Pressing Ctrl-Z SUSPENDS the job running in your foreground. Suspends means freezes: the job stops mid-work, right where it was, and the shell hands you back your prompt. The job is not gone. It is paused, sitting in the shell's job table, ready to be woken back up.

Say that word carefully, because it is the whole lesson: stopped is not terminated. A terminated job is dead and cannot come back. A stopped job is alive and frozen, holding its place and its progress, waiting for you to resume it. Think of Ctrl-Z as the pause button on a video, not the stop button. The picture holds still; press play and it carries on.

You resume a stopped job two ways, and both are their own lessons coming up next. fg brings it back to the foreground, front and center, holding the terminal again. bg sends it to the background, running quietly while you keep your prompt. For now, all you need is that a stopped job is resumable, and those two commands are how you resume it.

Under the hood, Ctrl-Z does not stop the job directly. It sends the job a signal, a one-word message the kernel delivers to a running process. The signal Ctrl-Z sends is named SIGTSTP. Read the name as terminal stop: the T at the front stands for terminal, and it means the request came from you at the keyboard, not from somewhere inside the program.

There is a whole family of these keyboard signals, and it is worth keeping them straight because they do very different things. Ctrl-Z sends SIGTSTP and STOPS a job (it can wake up again). Ctrl-C sends SIGINT and KILLS the foreground job (it interrupts and ends it). Ctrl-\ sends SIGQUIT and also kills it, more forcefully, often leaving a core dump behind. Only Ctrl-Z is a pause. The other two are exits.

To feel Ctrl-Z you first need something running in the foreground. sleep is perfect: it does nothing but wait for the number of seconds you give it, holding the terminal the whole time. Start one that waits a minute and a half, long enough that it will still be running when you reach for the keystroke.

Run it now. Once you press Enter, the prompt will vanish: sleep is holding the foreground, and that is exactly the situation Ctrl-Z is built for.

sleep 100

prompt: student@linuxcamp:~$ answer: sleep 100 output: hint: Type the word sleep, a space, then how many seconds to wait: sleep 100

sleep 100 prints nothing. It just holds the terminal for 100 seconds, which is the point: with the prompt gone, you now have a live foreground job to suspend. On the real machine this is the moment you would press Ctrl-Z.

The job is running and the prompt is gone. Now press Ctrl-Z: hold the Ctrl key and tap the Z key once. Because this is a keystroke, there is nothing to type and nothing to grade here. Instead, read what the shell prints back the instant you press it.

The shell prints one line and returns your prompt. Here is a representative frame of that moment:

^Z
[1]+  Stopped                 sleep 100
student@linuxcamp:~$

Read it piece by piece. The ^Z is the terminal echoing the keystroke you just pressed. The [1] is the job number the shell assigned this job. The + marks it as the current job, the one fg and bg act on by default. Stopped is the state, the word that tells you it is frozen and not dead. And sleep 100 is the command that got stopped, printed back so you know which job the line is about. After that line, your prompt returns: the terminal is yours again.

The [1] here is a job number, and it is an EXAMPLE. If you already had other jobs stopped or backgrounded, this one might be [2] or [3]. The job number counts jobs in this shell, it is not fixed. What is always true is the SHAPE of the line: a job number in brackets, a state word, and the command. On this machine the state reads Stopped, which is the word that matters.

The Stopped line flashed by once. To confirm the job is still there, frozen and waiting, ask the shell for its list of jobs. The jobs command prints the job table for your current shell: every job it is tracking, with its number and its state. This is your proof that Ctrl-Z paused the job instead of killing it.

With sleep 100 suspended, list the jobs:

jobs

prompt: student@linuxcamp:~$ answer: jobs output: [1]+ Stopped sleep 100 hint: One word, no options needed, just: jobs

There it is: the same job, still Stopped, sitting in the table. That is the point of the whole lesson made visible. Ctrl-Z did not end sleep 100, it froze it, and jobs finds it alive and paused. Your job number could differ from [1], but the Stopped state is what confirms the job is resumable. jobs is its own lesson coming up; here it is simply your evidence.

A frozen job is convenient, but it is not free. While it sits there stopped, it still exists: it keeps its process, its place in memory, and any files it had open. It is doing no work, but it has not let go of what it was holding. That matters because of one specific moment: trying to leave the shell.

If you type exit while a job is still stopped, bash does not just quietly close. It stops you and warns you, because closing the shell would abandon that frozen job. The warning is a fixed, literal line, the same on every machine:

student@linuxcamp:~$ exit
There are stopped jobs.

Bash prints There are stopped jobs. and does NOT exit. It is giving you a chance to deal with the job first, by resuming it with fg or by ending it on purpose. This is the one output in this lesson that is byte-for-byte identical everywhere, so it is worth memorising word for word.

Here is the real-world trap. The There are stopped jobs. warning only fires the FIRST time you try to exit. If you type exit a second time, bash gives up warning you and closes anyway, taking the stopped job down with it. And closing the terminal window outright, clicking the X, gives no warning at all. So the danger is forgetting: a job you paused with Ctrl-Z and then walked away from can be killed the moment you close the terminal without thinking. If it matters, resume it or finish it before you leave.

Scaffolding off. No command is printed this time. You have every piece you need.

Picture the situation. You started a job, pressed Ctrl-Z to freeze it, and got your prompt back. Now you want to prove to yourself that the job is still alive and merely stopped, not killed, before you decide what to do with it. Which single command lists the shell's jobs and shows you that Stopped state?

prompt: student@linuxcamp:~$ answer: jobs output: [1]+ Stopped sleep 100 hint: It is the one word that prints the shell's job table, with each job's number and state.

The command is jobs. It prints the shell's job table, and the Stopped state in that table is your proof that Ctrl-Z paused the job rather than ending it. Your own job number might read differently, but the state word is the thing to read: Stopped means frozen and resumable, ready for fg or bg. You recalled the command from what you needed it to do, which is exactly the recall the real machine will ask of you.

You earned this cheat sheet. The keystroke is the star, and the commands are how you work with what it leaves behind:

And the one line to keep in your head: stopped is not terminated. Ctrl-Z pauses, it does not kill. The job waits in the table with a Stopped state until you resume it, and bash will warn you There are stopped jobs. if you try to leave the shell while one is frozen.

The + next to a job number, as in [1]+, marks the current job. When you resume with a bare fg or bg and give no job number, that is the job the shell acts on. So the most recently stopped job is usually the one that comes back, which is what you want most of the time.

The practice terminal has shown you the shape of Ctrl-Z. You started a foreground job and saw the keystroke freeze it into a Stopped state. You read the jobs table that proves it is still alive, and you met the There are stopped jobs. warning that guards the exit. The keystroke you press; the commands around it you typed yourself.

The Job Control module ends with one real Linux machine, the Job Control capstone mission, and that is where you press Ctrl-Z for real, on jobs you can freeze, resume, and background. A VM boots just for you. It hands you objectives that use exactly what you practiced across this module: sending jobs to the background, suspending them, listing them, and bringing them back. One difference from here: the mission shows no commands. You read the objective, you recall the move, you make it. That recall is what makes it stick.

Finish the other Job Control lessons, then go freeze a real job and wake it back up.

Practice Ctrl-Z and SIGTSTP in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.