VMware ESXi and vSphere Cluster Management

Jobs Command in Unix and Linux Shells

Learn how the Unix and Linux jobs command lists and manages background, foreground, and stopped jobs in the current interactive shell.

What the jobs Command Does

The jobs command displays jobs tracked by the current interactive shell. A job is a command or pipeline that the shell knows how to control, such as a command running in the background or a command suspended with Ctrl+Z.

A shell job is not the same as every process running on the computer. Programs started by another terminal, a service manager, a different shell, or a detached session normally do not appear in this shell's job list.

Job control is the shell functionality used to move commands between the foreground, stopped, and background states. It lets you temporarily suspend a command, continue it while entering other commands, bring it back to the terminal, monitor it, or terminate it.

Prerequisites: Interactive Shells and Job Control

An interactive shell reads commands from you through a terminal and normally maintains a job table. Bash, Zsh, and many other Unix shells provide job control when connected to a suitable terminal.

A foreground job is connected to terminal input and normally receives keyboard-generated signals such as the signal generated by Ctrl+C or Ctrl+Z. A background job continues while the shell accepts another command. A stopped job is suspended and does not continue until it is resumed.

Job information is normally limited to the current shell and its controlling terminal. If you open a second terminal, that terminal has a different shell and usually a different job table. Job IDs also belong to the shell session that assigned them.

Reading jobs Output

Run the command without arguments to list jobs known to the current shell:

$ jobs
[1]-  Running                 sleep 300 &
[2]+  Stopped                 vi notes.txt

The number in brackets is the job ID. In this example, [1] and [2] identify jobs in this shell. A percent sign is used when referring to a job ID in commands, so job 2 is written as %2.

• + current-job marker: identifies the shell's default job. Commands such as fg may use this job when no job specification is supplied.
• - previous-job marker: identifies the alternate job selected by the shell.
• Running: the job is currently executing.
• Stopped: the job is suspended, commonly because you pressed Ctrl+Z.
• Done: the job completed. Shells may show this notification briefly and then remove the job from the table.

The command text at the end represents the command line or pipeline that the shell is tracking. For a pipeline, the displayed text may include every component, for example producer | consumer. Exact spacing and state wording vary between shells.

Annotated Output

[1]-  Running                 sleep 300 &
[2]+  Stopped                 cat | less

Here, 1 and 2 are shell job IDs, the minus and plus signs identify the previous and current jobs, the words describe job states, and the remaining text is the tracked command line.

Basic Usage

List Jobs

jobs

This lists active or retained jobs associated with the current shell. If there are no jobs, many shells produce no output and simply return to the prompt:

$ jobs
$

When a background command finishes, the shell may print a completion notification immediately or at the next prompt. After notification, a later jobs command may no longer show it. This behavior differs slightly between shells and shell versions.

Start a Background Job

sleep 300 &
jobs

The ampersand asks the shell to start sleep 300 as a background job. The shell commonly prints a job ID and a process ID when it starts the command, followed by a listing such as:

[1] 24871
[1]+  Running                 sleep 300 &

Job Specifications

A job specification is a shell reference that identifies a tracked job. Common forms include:

• %1 — job ID 1.
• %+ or %% — the current job.
• %- — the previous job.
• %command — a job whose command begins with the specified prefix, where supported.
• %?text — a job whose command line contains the specified substring, where supported.

For example:

fg %1
bg %-
kill %?backup

Prefix and substring matching are shell features. Their exact syntax, ambiguity rules, and support vary slightly between Bash, Zsh, and other shells. If a reference matches more than one job, the shell may report an ambiguity instead of choosing one.

Managing Jobs

Suspend, Resume, and Foreground a Command

Start a foreground command:

sleep 300

Press Ctrl+Z to suspend it. The shell normally reports that the job is stopped. Inspect it and resume it in the background:

jobs
bg %1

Use fg to return the job to the foreground:

fg %1

After fg, the command again owns the terminal's input. If the job is interactive, you can continue using it normally. The job may finish, be suspended again with Ctrl+Z, or be interrupted with a keyboard signal.

Wait for a Job

wait pauses the shell until a background job finishes. It is useful in scripts and at the command line when a later command depends on the result:

sleep 10 &
wait %1
echo "The job finished"

When waiting for a job, the shell can retrieve its completion status. In scripts, that status can be tested with $? immediately after wait.

Send a Signal with kill

kill accepts a job specification in shells that provide job control:

kill %1
jobs

Without a signal option, kill normally sends the default termination signal. A job specification can refer to a pipeline or process group tracked as one shell job. This differs from passing a numeric process ID, which targets an operating-system process.

Remove a Job from Shell Tracking

disown is a shell builtin available in shells such as Bash. It removes a job from the shell's job table:

disown %1

Afterward, the shell no longer manages that job as one of its jobs. Disowning does not automatically make a program safe from terminal input, output errors, or every form of session termination; use an appropriate detached execution method for the workload.

Common jobs Options in Bash

Bash commonly supports these options. Other shells may omit them or give them slightly different meanings.

For example, compare the normal listing with PID-oriented output:

jobs -l
jobs -p

jobs -l keeps the job ID, state, command, and associated process information visible. jobs -p prints process-group leader IDs, so its numeric output should not be mistaken for [1]-style shell job IDs.

Shell Job IDs and Process IDs

A process ID (PID) is an operating-system identifier for one process. A process group is a related group of processes, often corresponding to one pipeline or shell job. A shell job ID is a short, shell-local identifier assigned for job control.

Shell Job States

Job Control Command Reference

jobs Compared with Process-Management Tools

Use jobs for the small, shell-local view of commands started from the current interactive session. Use process-management tools when you need a system-wide or service-oriented view.

• ps displays detailed information about selected processes, including PIDs, parents, states, and command lines.
• pgrep searches for processes by name or other attributes.
• top provides a continuously updating process monitor.
• htop provides an interactive process monitor when installed.
• System service managers, such as a platform's service-management system, start, stop, restart, and monitor daemonized services. A service is not normally a job in your interactive shell.

A shell job may contain one process or several processes in a pipeline. The shell uses process groups to apply terminal foreground/background behavior to related processes. This is why a job reference can represent more than one operating-system process.

Scripts, SSH, Subshells, and Terminal Multiplexers

Job control is primarily designed for interactive shells. A script or noninteractive shell may not maintain the same job table, and a command such as jobs may produce no useful output. In scripts, explicit PIDs, wait, signal handling, and output redirection are usually more predictable.

Bash can enable job control with:

set -m

This is usually unnecessary in a normal interactive terminal. Enabling it in a script changes how process groups and asynchronous commands interact with the terminal, so use it only when the script specifically requires shell job control.

An SSH connection has its own shell and terminal context. Jobs started in one SSH session are not automatically visible in another. A subshell can also have different job-control behavior and does not provide a general-purpose shared job table for its parent shell.

Terminal multiplexers such as tmux and screen keep a terminal session available while you disconnect and reconnect. They are often more suitable than ordinary backgrounding for interactive programs.

What Happens When a Terminal Closes?

When a terminal or shell session ends, associated jobs may receive SIGHUP, the hangup signal. A job may then terminate, especially if it still depends on the terminal or the shell sends the signal during cleanup. Exact behavior depends on the shell, program, signal handling, and session configuration.

For a suitable noninteractive task, a basic approach is:

nohup long-task >long-task.log 2>&1 &
disown %1

nohup adjusts handling of hangup-related termination and commonly redirects output when needed. disown removes the job from the shell's tracking. Neither command replaces proper service supervision. For reliable long-running workloads, use tmux, screen, or a system service manager according to whether the task is interactive or a background service.

Troubleshooting

jobs Shows No Jobs but a Program Is Running

• The program may have been started in another terminal or shell.
• It may be a service, daemon, or detached process rather than a job tracked by this shell.
• It may already have completed and been removed after notification.

Return to the shell that launched the command when possible. Otherwise, use ps or pgrep to search for system processes.

A Background Command Stops Unexpectedly

A background command that tries to read from the terminal may be stopped by terminal job-control rules. Terminal output can also interact with terminal settings and cause a stop in some configurations. Bring the job forward with fg if it needs interactive input, or redirect its input and output before starting it:

long-task <input.txt >output.log 2>&1 &

fg or bg Reports No Such Job

Run jobs first. The job ID may be wrong, the job may have completed, or the command may be running in a different shell session. If you only have a PID, use process tools such as ps rather than a percent-prefixed job reference.

A Task Ends After the Terminal Closes

The shell or terminal may have sent SIGHUP to associated jobs. For suitable noninteractive tasks, consider nohup with explicit output redirection and, where appropriate, disown. Use tmux, screen, or a service manager when the task must survive disconnects reliably.

jobs Behaves Differently in a Script

Job control may be disabled in a noninteractive shell. Prefer explicit process IDs, wait, and signal handling for script concurrency. Consider set -m only when shell job control is specifically required.

Practical Workflow

1. Start a command in the background with command &, or suspend a foreground command with Ctrl+Z.
2. Run jobs to identify its shell job ID and state.
3. Use bg %1 to continue a stopped job in the background, or fg %1 to interact with it.
4. Use jobs -l when you need associated process information.
5. Use wait %1 when the shell must wait for completion.
6. Use kill %1 when the job should receive a termination signal.
7. Use ps, pgrep, top, or htop when the process is not in the current shell's job table.