Job Control Basics
Job control is the shell’s mechanism for managing multiple processes within a single terminal session. It lets you run multiple commands from one shell, move processes between foreground and background, and pause or resume processes. On servers, job control is frequently needed when you start a long-running command interactively and then want to check other things without killing it.
Foreground and background jobs
Foreground:
Terminal → [bash] → [long-running-command]
You cannot use the terminal until the command finishes.
Ctrl+C sends SIGINT to kill it.
Ctrl+Z sends SIGSTOP to pause it.
Background:
Terminal → [bash] → [command running in background] (job number &1;)
You can use the terminal for other commands.
Output from the background job may appear unexpectedly.# Start a command in the background (append &)
tar -czf /backup/home.tar.gz /home/ &
# Returns: [1] 12345
# [1] = job number, 12345 = PID
# Start another background job
rsync -av /data/ /backup/data/ &
# Returns: [2] 12346
Moving jobs between foreground and background
# Scenario: you ran a command, it's taking too long, you need the terminal back
# Step 1: Pause (stop) the foreground process
Ctrl+Z
# Output: [1]+ Stopped tar -czf /backup/home.tar.gz /home/
# Step 2: Resume it in the background
bg # Resume most recent stopped job in background
bg %1 # Resume specific job by job number
# Step 3: Bring a background job to the foreground
fg # Bring most recent job to foreground
fg %1 # Bring job 1 to foreground
fg %2 # Bring job 2 to foreground
# Step 4: Kill a specific job
kill %1 # Send SIGTERM to job 1
kill -9 %1 # Force kill job 1
The jobs command
# List all current jobs
jobs
jobs output
[1] Running tar -czf /backup/home.tar.gz /home/ &
[2]- Stopped vim /etc/nginx/nginx.conf
[3]+ Running rsync -av /data/ /backup/ &
# + = most recent job (default for fg/bg)
# - = second most recent
# Show jobs with PIDs
jobs -l
# Show jobs in a specific state
jobs -r # Running jobs only
jobs -s # Stopped jobs only
Keeping jobs alive after logout
Background jobs with & are child processes of your shell. When you log out, the shell sends SIGHUP to all its child processes, terminating them. To keep a process running after logout:
# Method 1: nohup (classic way)
nohup rsync -av /home/ /backup/ &
# Output goes to nohup.out unless redirected
nohup rsync -av /home/ /backup/ > /var/log/rsync.log 2>&1 &
# Method 2: disown (for already-running background jobs)
rsync -av /home/ /backup/ & # Start in background
disown %1 # Remove from job table (immune to HUP)
# Method 3: tmux or screen (best for interactive sessions)
sudo apt install -y tmux
tmux new-session -s backup
# Inside tmux: run your command
rsync -av /home/ /backup/
# Detach: Ctrl+B, then D
# Reconnect later: tmux attach -t backup
# Method 4: screen
sudo apt install -y screen
screen -S backup
# Inside screen: run command
# Detach: Ctrl+A, then D
# Reconnect: screen -r backup
💡 TIP: For long-running remote tasks on a server, always use tmux or screen instead of nohup. With tmux/screen you can reconnect and see live output, pause and inspect the process, and have multiple panes in one connection. If your SSH connection drops, the tmux session keeps running and you can reconnect exactly where you left off.
Conclusion
Job control essentials: & runs a command in background, Ctrl+Z pauses a foreground command, bg resumes it in background, fg brings it back to foreground, and jobs lists all jobs. For jobs that must survive logout, use tmux or screen — they provide a persistent session you can reconnect to. Use nohup command & or disown for simple cases where you just need the process to survive disconnection without interactive access.
FAQ
Why should administrators understand Job Control Basics?+
Because this topic affects planning decisions, server lifecycle, compatibility, support expectations, or how you reason about Ubuntu systems before making operational changes.
Do I need a lab for this topic?+
A lab is useful for checking commands and seeing the concept on a real Ubuntu machine, but the main value is understanding the decision, tradeoff, or system behavior clearly.
How should I use this knowledge in production?+
Use it to make better choices, document why those choices were made, and avoid rushed changes that ignore support windows, compatibility, stability, or operational risk.
Need help with Ubuntu administration?
Work directly with Muhammad Irfan Aslam for Ubuntu Server, Linux, cloud, Docker, DevOps, CI/CD, or infrastructure troubleshooting support.
Hire Me for Support