What is a job.
Abstraction. A pipeline is made of many processes, they are all in the same job.
I'm going to provide a brief overview, for more technical details see the "JOB CONTROL" section of the bash(1) manpage.
Starting a job in the background.
Similarly to how ending a command with
|| changes the logic
flow for the next command, ending a command with a single
& causes the
command to be run "in the background" i.e. while the command is running,
you can still enter other commands.
Identifying a running job
Immediately after running a background job, the
$! variable contains
the process ID of the last command to be run. This is different from
the job ID, but it is still rather useful, provided you are only running
one command at a time.
Additionally, bash will assign each job an ID, starting with the
symbol, so the first background job is
%+ all mean
the current job (i.e. most recent), and
%- refers to the previous job
(second most recent).
jobs command will list all active jobs, listing their job ID,
the command they are running, and markers to say which is the current
and which is the previous job.
Suspending a job.
^Z (holding Control and pressing Z) is the usual shortcut
key. This will return you to your shell prompt, and the job you were
running is suspended (i.e. processing stops, it will not print any more
Moving a job to the background.
bg command can be used to resume an existing job, while leaving
you access to the command line. Without any further options, it will
resume the latest command to be run.
bg can also be given a job spec
as described above.
bg %% and
bg %1 are all equivalent,
bg - and
Moving a job to the foreground.
fg will move a job to the foreground, so it would be identical to as
if it had been run without the
& specifier or suspended with
fg has all the short-cuts that
bg does, plus the job specifiers
themselves are synonymous to passing the job specifier to
is equivalent to
The background specifier
& can also be used with the
which makes it equivalent to
fg %1 & is equivalent to
The logical consequence of this is that
% & is equivalent to
Waiting for a job to finish.
wait command can be used to synchronise execution by waiting
until an existing command finishes before returning to the command-line,
or starting another job.
This differs from using the
fg command, as
wait may also be given
a process ID, as retrieved from
This is useful for when you have a long-running command, but you forgot
you need to run another command afterwards. To handle this, you can
^Z, then run
wait %+ && some_other_command.
Terminating a job.
There are a few ways to do this. You can foreground a job with
then kill it with
^C. Alternatively, you could kill the job with the
This is not the same as the kill(1) program. Unless you invoke
"$(which kill)", you will get the
kill built-in has the advantage of being able to be given a job
spec, such as
%1, instead of just a process ID.
Severing all ties with a job
Usually when a shell exits, it ensures all its child processes are terminated. This is a useful default behaviour, as it stops there being untidy processes being left around.
However, this is not always wanted, as you may care more about a job completing than being around to observe it.
Traditionally, this is solved by using the nohup(1) command, or running the process in a detached [screen(1)] session. However, both these approaches require you to know in advance that this job is going to take longer than you have your terminal open.
To solve this, bash has a
disown built-in command, which can remove
running commands from job-control, and optionally prevent them being
terminated by the shell.
$ some command </dev/null >~/nohup.out & $ disown -h %+
Is functionally equivalent to running
nohup some command. Running disown
-h won't prevent the process being killed when your shell exits.
Your shell will send the
SIGHUP signal to its child processes when
it exits, hence the naming of the nohup(1) command, and the
lwn is doing a series about process grouping. Later articles go into details about more modern Linux features, but the first article is good for a history of process management, and some technical discussions of how Job control works.