Here are two cases when a process group in an interactive shell isn't a job of the shell:

$ sleep 100 &
[1] 16081
$ jobs
[1]+  Running                 sleep 100 &
$ disown %1
$ jobs


$ ( sleep 200 & )
$ jobs

How does each case achieve making a process group not a job? In interactive bash, what is the necessary and sufficient condition for a process group to be a job of the shell?

The shell is a session leader running on a pseudoterminal slave. When the shell terminates, it will not affect the two sleep processes above, since they are not in the job list of the shell so don't receive SIGHUP. Then

  • do the two sleep processes still have the pseduoterminal slave as their session's controlling terminal?

  • What can terminate the two sleep processes, besides they exit normally or are killed by kill sending a signal?

I would like to know how different in effect the two cases are from a real daemon.

1 Answer 1


In both cases, the process group does start out as a job of the shell. When you call disown %1, the shell removes that entry from its list of jobs: that's the whole point of disown. With ( sleep 200 & ), the sleep process is a job of the subshell created by the parentheses; you can see that by running ( sleep 200 & jobs ). This one stops being the job of a shell when that shell exits; as with everything else, the subshell's jobs are its own, the parent never sees them.

The processes remain in the same session and still have the same controlling terminal. This has nothing to do with job control.

As with any process, they can be killed either by exiting or by receiving a signal. Since they aren't members of a foreground process group (and can't be, since the shell won't put them back into the foreground), they won't receive a kernel-generated SIGHUP if the terminal disappears.

A process group is a job of a shell if it started out as a job of that shell and it hasn't stopped being one. The details of what commands become separate jobs depends on the shell and is beyond the scope of this answer. In a nutshell, if a shell has job control enabled (which is the default if the shell is interactive), then each compound command is its own job. In particular:

  • A pipeline is a single job.
  • A command or process substitution is not a separate job, it runs in the original process group.
  • Anything running in the background (either started with & or backgrounded with Ctrl+Z) is a separate job.

A process group stops being a job if its leader exits, if the shell exits, or if the shell lets it go (with disown).

  • thx for concise overview. do you know any resource describing precisely what commands become separate jobs for bash, beyond these 3 cases you've described? somehow i struggle to find such a clear list anywhere...
    – Max
    Jan 25, 2023 at 14:34
  • 1
    @Max For sh in general: background job and asynchronous lists and follow cross-references (this is a standard, it's not didactic at all). Note the impact of set -b and set -m. Jan 25, 2023 at 17:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .