Jobs and foreground control
Understand shell-managed background work before losing track of it.
jobs
15 min read, 20 min lab
operator
A shell can suspend, background, foreground, and list jobs it started. This is local to that shell session, not the whole system process table.
You accidentally suspended a foreground command and need to recover control.
Worked command
$ sleep 300 &$ jobs$ fg %1# Ctrl-Z suspends$ bg %1Do not confuse shell jobs with all system services.
Use `jobs` for your shell, `ps` for the system.
In your shell `jobs` prints nothing, yet `ps aux` lists dozens of processes. Why?
Show the answer
Correct: B. jobs lists only jobs this shell session started; ps shows the whole system
jobs is scoped to the current shell's own job table, while ps reads the system-wide process table — so a quiet jobs list says nothing about other users, daemons, or other shells. Assuming ps is stale inverts the relationship; ps is the system view, not the unreliable one.
Practice checklist
- Start a background sleep.
- List it with `jobs`.
- Bring it foreground and stop it cleanly.
Deliverable evidence
- A transcript showing jobs, fg, bg, and cleanup.
shows: The triage path: a symptom sorts into a resource class (CPU, memory, disk bytes, inodes), each with its own first command, then narrows to a named process or constraint before any TERM/KILL or restart.
does not prove: It shows the order of checks, not the verdict: running these commands gathers evidence but does not by itself prove which resource is the true bottleneck — you still have to read the numbers and reason about available vs free, bytes vs inodes.
Commit these to memory, then drill them until recall is automatic.
cue A command is suspended (you hit Ctrl-Z); resume it in the background as job 1
show recall target
bg %1