bg

bg - a hands-on Linux lab on a real virtual machine.

Rescue a job you started without an & using bg. Ctrl+Z stops it, then bg resumes it in the background so your prompt stays free and no progress is lost. Bare bg for the most recent stopped job, bg %n to name one, jobs to confirm it is Running. Job numbers and PIDs are assigned live, so the drills teach the moves and the Stopped-to-& shape; your numbers vary.

You kick off a long job, a big copy, a slow build, a download that will take five minutes. The second you press Enter you realise your mistake: you forgot to put an & on the end. Now the command has the terminal by the throat. It will not give your prompt back until it finishes, and you have other work to do.

Most people kill it and start over, losing whatever progress it made. You are about to learn the fix that a working engineer reaches for instead: stop the job where it stands, then hand it to the background without losing a second of progress. The command that finishes that rescue is two letters long. It is called bg.

The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches. Two honest catches, unique to this lesson. First, the number in brackets like [1] is a job number and the long number beside it is a PID (process ID); the shell assigns both live, so yours will differ from the captures here. Second, Ctrl+Z is a key combination you press, not a command you type, so the sandbox only grades the bg you type after it. The Stopped lines you see are shown as examples of what the real shell prints back.

bg is short for background. It takes a job that is stopped (paused, frozen in place, using no processor time) and sets it running again, but this time in the background, so it keeps working while your prompt comes back to you. The job did not restart from zero; it picks up exactly where it froze.

This lesson is the third beat of a three-part rescue you have already met the pieces of. In the & lesson you learned to launch a job in the background from the start by putting & on the end. In the Ctrl-Z lesson you learned that pressing Ctrl+Z stops a running job and freezes it. bg is what you run right after that Ctrl+Z: it un-freezes the stopped job into the background. Ctrl+Z pauses; bg resumes, out of your way.

Put simply, bg is the undo button for a forgotten &. You meant to type sleep 100 &, you typed sleep 100, and the prompt hung. Ctrl+Z then bg gets you to the exact same place as if you had typed the & all along, with no progress lost.

Let us walk the whole rescue once, slowly. You start a job that just waits 100 seconds, and you forget the &. The prompt hangs; you cannot type. So you press Ctrl+Z. The shell freezes the job and prints a Stopped line, and your prompt returns.

Here is that first half, shown as an example so you can read the shape. You do not type the Ctrl+Z part; that is a key press:

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

Read that middle line. [1] is the job number the shell gave this job. + marks it as the current job (the most recent one). Stopped means it is frozen, and sleep 100 is the command it froze on. The job is paused right now, using no processor, waiting for you.

Now the payoff. Type bg on its own. With no argument, bg acts on the most recent stopped job, which is exactly the one you just froze. It resumes that job in the background and prints it back with an & on the end, the same & you meant to type in the first place:

bg

prompt: student@linuxcamp:~$ answer: bg output: [1]+ sleep 100 & hint: Just the two letters, no argument. bg acts on the most recent stopped job: bg

The [1] here is this capture's job number; on your machine the same rescue might print [2] or [3] depending on how many jobs you already have. What matters is the SHAPE: bg echoes the job back with an & on the end, and that & is the whole point. It confirms the job is now running in the background, exactly as if you had launched it with & to begin with.

Read the delta. Before bg, the line said Stopped. After bg, the same job reads sleep 100 &, with no Stopped in sight and an & on the end. That flip from Stopped to & is bg doing its one job: it un-froze the paused job and pushed it into the background. Your prompt is already back, and the sleep is quietly counting down behind it. You rescued a forgotten & in two moves, Ctrl+Z then bg, and lost none of the progress the job had made.

You have bg's word that the job is in the background. Trust, but verify. The jobs command (its own lesson comes next) lists every job this shell is tracking and its current state. Run it right after bg and you should see your job marked Running, not Stopped.

jobs

prompt: student@linuxcamp:~$ answer: jobs output: [1]+ Running sleep 100 & hint: The command that lists background and stopped jobs is jobs: jobs

The state word is what you came to read: Running, where a moment ago it said Stopped. That single word is proof bg worked. As always, the [1] job number is this machine's; yours may differ. The state, Running, is what stays true everywhere after a successful bg.

Bare bg grabs the most recent stopped job, which is what you want most of the time. But what if you have stopped several jobs and want to resume a specific one, not just the newest? You name it with a percent sign and its job number. bg %1 means resume job 1. The % is how you point job-control commands at a job by its bracket number.

Say you stopped a job and it came back as [1]. To send that exact job to the background, you name it:

bg %1

prompt: student@linuxcamp:~$ answer: bg %1 output: [1]+ sleep 100 & hint: Percent sign, then the job number from the brackets. To resume job 1: bg %1

bg %1 and bare bg printed the same line here only because job 1 happened to be the most recent stopped job. The difference is aim: bare bg always takes the newest stopped job, while bg %1 takes the job you named no matter how many others are stopped. Your own job numbers will differ; the %n move is what to remember.

bg works cleanly for jobs that just churn away on their own, a copy, a build, a sleep. But some programs need to read from the keyboard while they run. Push one of those into the background and it hits a wall: it tries to read your typing, but a background job is not allowed to. So the shell stops it again, on the spot, with a telling message.

You will not type this; it is a frame to recognise. A backgrounded job that reaches for keyboard input freezes itself and prints:

[1]+  Stopped (tty input)     some-interactive-command

The words (tty input) are the clue. tty means the terminal, your keyboard and screen. Stopped (tty input) means the job stopped because it tried to read from the keyboard while sitting in the background, which it cannot do. The fix is not another bg; that would just stop it again. Bring this job back to the FOREGROUND instead, with fg, the command in the next lesson, so it can talk to your keyboard.

bg is for jobs that run without needing you. If a job keeps landing back on Stopped (tty input) every time you bg it, that is the job telling you it needs the keyboard. Stop fighting it with bg and pull it forward with fg instead.

Three bg errors are worth knowing on sight, because each points at a different mistake.

bash: bg: no current job. You ran bg but there is no stopped job for it to resume. Either you never stopped anything, or the job already finished. What to check first: run jobs. If it prints nothing, there is no job to background, and that is why bg had nothing to do.

bash: bg: job 1 already in background. You tried to bg a job that is already running in the background. bg resumes STOPPED jobs; this one was never stopped, so there is nothing to resume. What to check first: run jobs and read the state. If it already says Running, the job is right where you wanted it.

bash: bg: %2: no such job. You named a job number that does not exist. There is no job 2 in this shell, so %2 points at nothing. What to check first: run jobs to see the real job numbers, then bg the one that is actually there.

Notice the cure for all three is the same first move: run jobs. It shows you which jobs exist and what state each is in, which answers every one of these errors before you guess. When bg complains, list before you retry.

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

You started a long job and forgot the &, so your prompt is stuck. You have already pressed Ctrl+Z, and the shell froze the job and handed your prompt back with a Stopped line. Only one thing is left: resume that stopped job in the background so it keeps running and your prompt stays free. It is the most recent stopped job, so you do not need to name a number.

prompt: student@linuxcamp:~$ answer: bg output: [1]+ sleep 100 & hint: The most recent stopped job needs no job number. Two letters, on their own: bg

Bare bg was the whole answer. Because the job you just stopped is the most recent one, bg with no argument found it, resumed it, and pushed it into the background, echoing it back with the & on the end. Your prompt is free and the job runs on. That two-move rescue, Ctrl+Z then bg, is the everyday fix for a forgotten &. You recalled the final move with no command in front of you, which is exactly the recall the real machine will ask of you.

You earned this cheat sheet. Every row is a form of bg or a partner move you just used:

And the shape you can now read: after a successful bg, the job echoes back with an & on the end and jobs reports it Running. If it keeps coming back Stopped (tty input), that job needs the keyboard, so use fg instead.

The full rescue is three commands you have now met: Ctrl+Z to stop a running job, bg to resume it in the background, and fg (next lesson) to pull a background job back to the front. Together they let you move any job between foreground and background at will, which is the heart of job control.

The practice terminal has shown you the shape of bg. You have the Ctrl+Z-then-bg rescue, bare bg for the most recent stopped job, bg %n to name one, jobs to confirm it is Running, and the Stopped (tty input) gotcha that means reach for fg instead. Every bg you typed yourself, and the last one you recalled with no command in front of you.

The Job Control module ends with one real Linux machine, the Job Control capstone mission, and that is where you run bg for real, against jobs that actually stop and resume while you watch. A VM boots just for you. It hands you objectives that use exactly what you practiced across this module: backgrounding jobs, stopping them, resuming them, and moving them between foreground and background. One difference from here: the mission shows no commands. You read the objective, you recall the command, you type it. That recall is what makes it stick.

Finish the other Job Control lessons, then go rescue a real job for yourself.

Practice bg in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.