Job Control &, fg, bg, jobs

When working in the Linux terminal, long-running commands don't have to keep your shell occupied. Linux job control allows you to pause, resume, move, and manage running processes without stopping them, making it easier to work efficiently from a single terminal session.

In this guide, you'll learn how to use Linux job control with jobs, fg, bg, and the background operator (&). We'll also cover practical examples, common mistakes, and best practices for managing foreground and background processes, whether you're a beginner learning the Linux command line or an experienced administrator working on production systems.

Examples

Job control is just a fancy name for pausing, resuming, and switching commands between the foreground and background inside a single shell session. That's it. Nothing about it needs to feel abstract once you've done it a couple of times.

Technically, every command you type in bash becomes a "job" the moment it starts running, and the shell keeps a small table tracking each one, whether it's actively running in the foreground, paused, or humming along quietly in the background. You interact with that table using three tools: jobs to list what's running, fg to bring something back to the front, and bg to send a paused command off to run in the background. This matters the moment you're doing more than one thing at once in a terminal, which for most people running Linux day to day is basically always.

Think about the last time you kicked off a backup, a big file copy, or a long compile and then just sat there staring at the terminal doing nothing else. That wasted time is exactly what job control gets rid of, and it's the same instinct behind a lot of the terminal tricks that make you faster day to day.

jobs on its own lists everything the current shell knows about. fg and bg both take an optional job specifier written as a percent sign followed by a number, like %1 or %2. Leave the job ID off and either command just acts on whatever job is currently marked as the "current" one, which is usually the most recently backgrounded or suspended command.

Before you background or foreground anything, it helps to actually see what the shell thinks is going on. This is usually the first command people learn and the last one they stop using.

If you already know a command is going to take a while, put an ampersand at the end from the start. Your prompt returns immediately and the command keeps working behind the scenes.

That number in brackets is the job number, and the second number is the PID. You'll see both again in jobs -l.

This is the one people forget exists. If you forgot to add the ampersand and a command is already hogging your terminal, you're not stuck. Ctrl+Z suspends it on the spot.

Stopped does not mean killed. The process is frozen in place and using no CPU, but it's still there waiting.

Now that the job from the last example is sitting stopped, bg wakes it back up and keeps it out of your way.

Once you're juggling more than one background job, plain jobs stops being enough. Add -l when you actually need the PID to hand off to ps or kill.

Once you're this deep into process tracking, our ps command guide is a natural next stop for viewing everything running on the system, not just what's tied to your shell. If you'd rather watch things live instead of taking a snapshot, htop shows the same processes updating in real time.

With more than one job running, plain fg grabs whatever's marked current, which isn't always the one you want. Target it directly with the job number.

If you actually want to end that job rather than look at it, you don't need to foreground it first just to Ctrl+C it. kill %2 sends the signal directly using the job number, which is faster and safer than hunting down the PID with ps.

If you know ahead of time a job needs to outlive your terminal session, plan for it up front instead of scrambling with disown afterward.

Database migrations and long exports like this one are exactly where an underpowered VPS shows its limits, disk I/O in particular gets ugly fast. If you're picking a provider for that kind of workload, our Vultr review breaks down how it actually performs under sustained load rather than just on paper specs.

This one catches people constantly, including me the first time it happened, and it's confusing precisely because bash is inconsistent about it.

Since you can't fully control which one happens, the honest fix is to stop relying on the distinction at all. If you know before you start that the job needs to outlive the session, launch it with nohup:

If the job is already running and you only realize now that you need it to survive, skip nohup (it only works at launch) and detach it instead:

Pick one or the other depending on timing, there's no need to stack both. Neither one is completely bulletproof though. nohup and disown only block the SIGHUP signal itself, and a job that reads or writes to a terminal that's no longer there can still misbehave. For anything that genuinely needs to survive across sessions and keep producing output you can come back to, a terminal multiplexer is the more reliable habit:

Run your long job inside that tmux session as normal, no ampersand needed, then detach with Ctrl+B followed by D whenever you need to disconnect. The whole session, including any live output, keeps running on the server and you reattach later with tmux attach -t work. screen works the same way if that's what's already installed. If you need something more bulletproof than nohup for a single stubborn process without pulling in a multiplexer, setsid nohup ./long_task.sh > task.log 2>&1 </dev/null & fully detaches the process into its own session so it isn't part of your shell's process group at all, which is the same trick daemons use to survive their parent shell no matter how it exits. If you're running scheduled or long lived tasks anyway, it's worth reading how we moved from cron jobs to systemd timers, since anything that needs to run unattended long term is usually better off there than in a job at all.

Once you're comfortable backgrounding one thing, the next natural step is backgrounding several and waiting for all of them before moving on, which is common in backup and deployment scripts.

Both tar commands run in parallel instead of one after another, and wait with no arguments blocks until every background job in the current shell has completed before the script continues. This is the same building block behind a lot of the process management cheat sheet, worth a look if you're writing scripts that juggle more than one task at a time.

Without job control, every terminal session turns into a queue. You run one thing, wait, run the next, wait again, and if you need to check something else you're stuck opening a new window or a new SSH connection just to avoid interrupting whatever's already running. On a laptop that's mildly annoying. On a production server where you're managing dozens of small tasks across a shift, it adds up to real wasted time and real risk, because more open sessions means more places where something can be left running and forgotten.

What actually shifts once you're comfortable with jobs, fg, and bg is how casually you start things. You stop being precious about whether a command is "worth" backgrounding and just do it by default for anything that takes more than a few seconds. That habit alone changes how you work, because you're no longer blocked waiting on your own terminal. It also forces you to think about SIGHUP and process lifetime earlier than most people do, which pays off the first time a client asks why a job died the moment you disconnected.

Underneath all of this is process group membership, which is the part most tutorials skip. When you start a job, its processes get placed in a process group tied to your shell's session. That's the actual mechanism behind SIGHUP propagating to background jobs on a real hangup, the terminal driver signals the whole session, not each process individually, which is also why disown and setsid work the way they do: disown just stops the shell from resending the signal, while setsid moves a process into a brand new session entirely so it was never reachable through your terminal's session in the first place.

The gap most guides skip is what happens at the edges: SSH sessions that drop, scripts that assume an interactive shell and throw the no job control in this shell error, and jobs that quietly vanish because nobody thought about nohup until after the fact. Bash documents the mechanics of this well in its own manual, and the official GNU Bash job control reference is worth skimming once you've got the basics down, since it covers signal behavior in more depth than any blog post reasonably can.