jobs
Overview
jobs lists active jobs of the current shell: running background tasks, stopped jobs, and their job IDs. Essential for job control with fg, bg, kill %n, and wait.
Jobs are not a system-wide process table — use ps/pgrep for that.
Syntax
jobs [options] [job_spec ...]Common Options (bash)
| Option | Description |
|---|---|
-l |
Include PIDs |
-p |
PIDs only |
-n |
Only jobs with status changes since last notification |
-r |
Running only |
-s |
Stopped only |
-x command |
Replace job specs in command with PIDs and run |
Job states
| State | Meaning |
|---|---|
| Running | Executing in background |
| Stopped | Suspended (Ctrl-Z / SIGSTOP) |
| Done | Completed successfully |
| Exit N | Exited with status N |
| Terminated | Killed by signal |
Examples with Explanations
List jobs
sleep 300 &
sleep 400 &
jobs
jobs -l
jobs -p
jobs -r
jobs -sAct on a job
jobs -l
fg %1
bg %2
kill %1
kill -9 %2Status changes
jobs -nUseful after many completions to see what finished.
wait integration
longtask &
pid=$!
jobs -l
wait "$pid"Enable job control in scripts (rare)
set -m
sleep 5 &
jobs -l
waitdisown removes from table
sleep 1000 &
jobs
disown
jobs # empty regarding that job
# process may still run — check psNotes / Pitfalls
- Empty
jobsdoes not mean no processes exist — only no shell jobs. - Job IDs are not PIDs; use
jobs -lor$!for PIDs. - Subshells have their own job tables:
( sleep 10 & jobs ). - Non-interactive shells often disable job control until
set -m. - Don’t use
jobsfor service supervision — use systemd.
2026-relevant notes
- Interactive terminal multiplexers reduced reliance on many concurrent jobs, but
%job specs remain daily muscle memory. - CI shells may not support job control the same way — use PIDs +
wait. - For parallel shell work, GNU
parallelorxargs -Pmay be clearer than raw jobs.
Additional Resources
help jobs,man bash