bg

What it does

bg is a shell built-in (available in bash, zsh, and other job-control-capable shells) that resumes a stopped job and continues running it in the background instead of the foreground. The typical workflow is: you start a long-running command, realize you need your terminal back, press Ctrl+Z to suspend it (sending SIGTSTP), and then run bg to let it keep running without blocking your prompt. It works together with fg (bring a job to the foreground), jobs (list current jobs), and the & suffix (start a command already in the background) as the core of shell job control.

Beginner examples

• Start a long command, then press Ctrl+Z to suspend it
• bg — resume the most recently stopped job, now running in the background
• jobs — list current jobs and their state (Running, Stopped) with job numbers
• bg %1 — resume job number 1 specifically, in the background

# start something long-running
find / -name "*.log" > /tmp/all_logs.txt
# press Ctrl+Z to stop it, then:
bg

Advanced examples

• Background multiple stopped jobs by job number: bg %1 %2
• Resume the previous (not current) job explicitly: bg %-
• Match a job by its command name instead of number: bg %rsync
• Check a backgrounded job's status afterward: jobs -l
• Redirect a job's output before backgrounding it (needs to be set up before stopping, or reopened) so it doesn't clutter the terminal: long_command > output.log 2>&1 then Ctrl+Z then bg

jobs -l
bg %2

Common mistakes

• Trying to background a job that never ran in the foreground of the current shell (e.g. a process from another terminal) — bg only operates on jobs known to the current shell's job table, not arbitrary system processes; use kill/ps for those.
• Forgetting that a backgrounded job still writes to the terminal's stdout/stderr unless redirected, which can interleave confusingly with whatever you type next.
• Assuming bg restarts a command from the beginning — it doesn't; it resumes exactly where the stopped process left off (via SIGCONT), preserving its existing state.
• Closing the terminal (or losing the SSH session) after backgrounding a job and being surprised it dies anyway — a backgrounded job is still a child of that shell and, in most default configurations, gets SIGHUP when the shell exits, unless started with nohup/disown or run inside tmux/screen.

Tips

• Run jobs before bg/fg if more than one job is stopped, so you background the right one by its job number rather than assuming it's "the current job."
• Use disown after bg if you want the job to survive even after you close the terminal session, since a plain backgrounded job is still tied to the shell.
• Combine with output redirection at launch time (command > out.log 2>&1 &) to avoid ever needing to background it manually — cleaner than stopping and resuming.
• If a job needs input from the terminal, backgrounding it with bg will usually cause it to stop again (SIGTTIN) the moment it tries to read stdin — redirect its input from a file or /dev/null instead.

Best practices

• Prefer starting commands with a trailing & from the outset when you already know you want them in the background, reserving Ctrl+Z + bg for cases where you change your mind mid-run.
• Pair long background jobs with nohup or disown (and output redirection) if they need to survive terminal/session closure, rather than relying on the shell staying open.
• Use a terminal multiplexer (tmux, screen) for genuinely long-running background work on a remote server instead of relying solely on shell job control, which is tied to that one shell session.
• Check jobs regularly during a session with several backgrounded tasks so you don't lose track of which job number corresponds to which command.

Real-world use cases

• Freeing up a terminal to run other commands while a large rsync or find operation you started in the foreground keeps running in the background.
• Backgrounding a command you started without redirecting output, so you can keep working while occasionally checking on it with jobs or bringing it back with fg.
• Managing several ad hoc long-running tasks in one interactive SSH session (e.g. a build, a log tail, a sync) by stopping and backgrounding each with Ctrl+Z + bg, then switching between them with fg %n.

Common interview questions

• What's the difference between running a command with & and stopping it with Ctrl+Z then running bg? & backgrounds a command from the moment it starts; Ctrl+Z + bg is for a command already running in the foreground that you decide to move to the background afterward, without restarting it.
• What happens to a backgrounded job if you close the terminal? By default it typically receives SIGHUP and terminates, unless it was started with nohup, detached with disown, or run inside a persistent session like tmux/screen.
• How do you bring a specific backgrounded job back to the foreground? fg %n, where n is the job number shown by jobs (or fg %- for the previous job, fg alone for the current one).