Linux jobs Command: View and Manage Shell Jobs

Learn how the Linux jobs command lists shell jobs, explains job IDs and states, and works with fg, bg, kill, and process IDs.

The Linux jobs command displays commands that the current interactive shell is tracking as jobs. It helps you identify a job's shell-local number and state before using commands such as fg, bg, or kill.

What Shell Job Control Means

Job control is the cooperation between an interactive shell and the terminal to stop, resume, foreground, and background commands. A job is a command or pipeline launched from one interactive shell session. A pipeline, such as producer | consumer, is generally tracked as one shell job even though it can contain multiple processes.

A foreground process group is attached to the terminal and can receive terminal input. A background job runs without occupying the shell prompt. A stopped job is paused, commonly because you pressed Ctrl+Z, which sends a terminal stop signal.

Shell job tracking is different from system-wide process management. The shell maintains its own job table, while the operating system assigns process IDs (PIDs) to individual processes. The jobs command inspects only jobs known to the current shell; it is not a general process viewer.

What `jobs` Displays

Run jobs without arguments to list the active jobs tracked by the current shell:

jobs

Typical output resembles this:

[1]-  Running    sleep 300 &
[2]+  Stopped    vim notes.txt

The output commonly contains these fields:

Job number: The number in brackets, such as 1 or 2.
Current and previous markers: A + marks the current job, and a - marks the previous job. These markers help commands choose a default job.
State: Common states include Running, Stopped, and Done.
Command text: The command or pipeline associated with the job.

Common Job States

Running — The job is executing. Typical next action: leave it in the background, or use fg to attach it to the terminal.

Stopped — The job is paused. Typical next action: use fg or bg to resume it.

Done — The job completed. The shell may report it briefly and then remove it from the job table.

Completed jobs may disappear after the shell reports them or after you run jobs, depending on the shell and its notification behavior. Therefore, an empty result does not necessarily mean that no command recently ran.

Job IDs, Job Specifications, and PIDs

A job ID is a numeric identifier assigned by the current shell. It is normally shown in brackets by jobs, and it usually starts over in a new shell session. A job specification is the notation used to select a job; it normally begins with %.

Job Specifications and Markers

%1 — Selects job 1. Example: fg %1.

%% — Selects the current job. Example: bg %%.

%+ — Another notation for the current job. Example: kill %+ .

%- — Selects the previous job. Example: fg %-.

The space before the closing code marker in the kill %+ example is not needed in a real command; use kill %+ only if your shell accepts the trailing whitespace, or preferably type kill %+ without the extra space. More generally, use the exact job specification printed or supported by your shell.

A PID is an operating-system process identifier. A job ID identifies a shell-managed job, which can represent a pipeline or process group. A PID identifies one process. They are not interchangeable.

Job ID Versus PID

Assigned by: A job ID is assigned by the shell; a PID is assigned by the operating system.

Scope: A job ID belongs to one shell session; a PID is system-wide while that process exists.

Typical syntax: A job specification is written like %1; a PID is written as an ordinary number such as 4821.

Used with: Use job specifications with fg and bg; use PIDs with tools such as ps.

Persistence: Job IDs can be reused by a later shell; PIDs can also be reused by the operating system after a process exits.

How to view it: Use jobs for job IDs and jobs -l or ps for PIDs.

Creating Foreground, Background, and Stopped Jobs

Foreground commands

A command normally starts in the foreground. The shell waits for it to finish, and the command receives terminal input:

sleep 10

Background commands

Append & to launch a command as a background job. The shell prints a job number and usually a PID, then returns the prompt:

sleep 300 &
jobs

Example output:

[1]+  Running    sleep 300 &

Stopped commands

Start an interactive command in the foreground, then press Ctrl+Z to suspend it:

vim notes.txt

After pressing Ctrl+Z, inspect the shell's job table:

jobs

The editor should appear as Stopped. Suspending a job pauses it; it does not normally terminate it.

Basic Use of `jobs`

With no options, jobs typically reports all active shell jobs:

jobs

Read the number in brackets, check the state, and use the number as a percent-prefixed job specification. For example, if the output contains [2]+ Stopped, select it with %2:

fg %2

The job number is useful because it lets you choose exactly which shell job to foreground, background, or terminate.

Useful `jobs` Options

jobs Command Options

-l — Include process IDs. Typical use: jobs -l. Support and formatting are generally similar in job-control shells, but output can differ.

-p — Print process IDs, usually one PID per job. Typical use: jobs -p. Shells can differ in whether they print a representative PID or all relevant process IDs for a pipeline.

-r — Show running jobs only. Typical use: jobs -r.

-s — Show stopped jobs only. Typical use: jobs -s.

-n — Show jobs whose status changed since the last notification, where supported. Typical use: jobs -n.

-x command [arguments] — Substitute job-related process IDs into the command, where supported. This is useful when another command expects process IDs rather than job specifications.

For example, compare a shell job number with its PID:

sleep 300 &
jobs -l
ps -p <pid-from-jobs-output> -o pid,stat,command

Replace <pid-from-jobs-output> with the actual PID printed by jobs -l. Do not type the angle brackets.

jobs is generally a shell builtin, not a standalone process-management utility. Exact options, output, and the behavior of -p, -n, and -x can differ between Bash, Zsh, and other shells. In Bash, inspect builtin help with:

help jobs

You can identify the active shell with commands such as:

echo $0
ps -p $$

Using Job Output with Job-Control Commands

Bring a job to the foreground

Use fg with a job specification to resume or attach a job to the terminal:

fg %1

This resumes job 1 if it was stopped and gives it foreground terminal control. The shell prompt will not return until the foreground job exits, is stopped, or otherwise releases control.

Resume a job in the background

Use bg to resume a stopped job without bringing it into the foreground:

bg %1

The shell prompt returns while the job continues in the background.

Use current and previous jobs

The + and - markers identify the current and previous jobs. You can select them with %% or %+, and %-:

fg %%
bg %-

These shortcuts are convenient when the desired job is current or previous, but a numeric specification such as %2 is clearer when several jobs are listed.

Terminate a shell job

When supported by the shell, pass a job specification to kill:

kill %1

This sends the default termination signal to the selected shell job. If a process-oriented tool requires a PID, use the PID from jobs -l instead.

Practical Workflow with Multiple Jobs

The following workflow creates several stopped jobs, lists them, resumes one in the foreground, resumes another in the background, and verifies the states.

vim notes.txt
# Press Ctrl+Z
find /tmp -type f > /tmp/files.list
# Press Ctrl+Z
dd if=/dev/zero of=/tmp/test.img bs=1M count=100
# Press Ctrl+Z
jobs

Each suspended command receives a job number in the current shell. The output might look like this:

[1]+  Stopped    vim notes.txt
[2]-  Stopped    find /tmp -type f > /tmp/files.list
[3]   Stopped    dd if=/dev/zero of=/tmp/test.img bs=1M count=100

Choose job 2 and resume it in the foreground:

fg %2

After the foreground command finishes or is stopped again, select a stopped job and resume it in the background:

jobs -s
bg %1
jobs -r

Use a safe, writable path for the dd example. The command writes a 100 MiB file and may be unsuitable on a system with limited disk space. You can omit it or reduce count in a practice environment.

Scope and Limitations

jobs does not list processes from another terminal, another shell, or the entire machine. If you start sleep 300 in one terminal and run jobs in a second terminal, the second shell normally shows nothing for that command.

For system-wide process inspection, use process-oriented tools:

ps displays process snapshots and details such as PIDs, states, and commands.
pgrep searches for processes by name or other attributes.
top provides an updating process view.
htop provides an interactive process view when installed.
Service-management tools are appropriate for processes managed as system services.

Non-interactive scripts commonly do not have usable job control. In automation, track background child processes with $! and wait for them with wait rather than relying on an interactive job table. In a controlled shell context, set -m can enable job control in shells that support it, but validate the behavior before depending on it in a script.

Troubleshooting

`jobs` shows no entries, but another terminal has running programs

The commands belong to another shell session. Return to the terminal that started them, or use ps, pgrep, top, or htop for system-wide discovery.

`fg: no such job` or `bg: no such job`

The job number may be invalid, may belong to another shell, or the job may already have exited. Run jobs in the same shell and use a currently displayed specification such as %2.

A PID was supplied to `fg` or `bg`

fg and bg expect a shell job specification, not an ordinary PID. Run jobs, find the shell job number, and use a form such as fg %2. Use ps or PID-oriented forms of kill when working with a PID.

`jobs` is empty in a script

Non-interactive shells often have job control disabled or do not maintain an interactive job table. Track child PIDs with $! and use wait, or explicitly enable and test job control only when appropriate.

A background job stops while reading from the terminal

A background process that attempts terminal input can be stopped by terminal job-control signals. Bring it forward with fg, redesign it to avoid interactive input, or redirect its input appropriately.

A job disappears from the list

The command may have completed, been terminated, or been cleared after the shell reported its completion. Check the shell's recent output, inspect expected result files, or use process-monitoring tools if the command should still be active.

Options or formatting differ between shells

jobs is a shell builtin, so support varies. Check the active shell with echo $0 or ps -p $$, then consult that shell's builtin documentation, such as Bash's help jobs.

Exam-Relevant Notes

jobs lists jobs tracked by the current shell, not all system processes.
A job ID is shell-local and is referenced as a job specification such as %1.
A PID identifies an operating-system process and is distinct from a job ID.
Ctrl+Z stops a foreground job; it does not normally terminate it.
fg %1 resumes job 1 in the foreground, while bg %1 resumes it in the background.
%% and %+ refer to the current job; %- refers to the previous job.
jobs -l includes PIDs, while jobs -r and jobs -s filter running and stopped jobs.

For related shell fundamentals, see Bourne Again Shell Bash and the Linux command-line topics.