Bash – Does (sleep 123 &) Remove the Process Group from Job Control?

background-processbashjob-controlsignals

Does the following way

$ (sleep 123 &)
$ jobs
$

remove the process group of sleep 123 from bash's job control? What is the difference between the above way and disown then?
Note that the sleep 123 process is still in the same process group led by the now disappearing subshell, and in the same process session as the interactive shell, so share the same controlling terminal.

Does not being in the shell's job control explain that the sleep 123 process will not receive any signal (including SIGHUP) sent from the bash process?

Thanks.

Best Answer

Yes, it removes it, so to speak.

When you run a (...) subshell from an interactive bash script, a new process group (job) is created, which becomes the foreground process group on the terminal, and in the case where the subshell contains any command terminated by &, (eg. sleep 3600 &) that command will be started in the very same foreground process group, with SIGINT and SIGQUIT ignored and its input redirected from /dev/null). See here for some links to the standard.

When the (...) subshell exits, that foreground job is removed from the shell's jobs table, and the sleep 3600 command will continue to run outside of the control of the shell.

This is quite different from the case where (sleep 3600 &) is run from a non-interactive script with no job control, where everything (the main shell, its (...) subshell, and any "background" commands (foo &), inside or outside the (...) subshell) is run in the same process group.

Related Solutions

SSH Signals – When SIGHUP is Not Sent to a Job on Logout

Bash seems to send the SIGHUP only if it self received a SIGHUP, which for example occurs when a virtual terminal is closed or when the SSH connection is interrupted. From the documentation:

The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell resends the SIGHUP to all jobs, running or stopped. Stopped jobs are sent SIGCONT to ensure that they receive the SIGHUP. To prevent the shell from sending the SIGHUP signal to a particular job, it should be removed from the jobs table with the disown builtin (see Job Control Builtins) or marked to not receive SIGHUP using disown -h.

So if you type exit or press Ctrl+D all background process will remain, since this does not send a hang up signal to the Bash.

You can force Bash to warn you about the fact that there are still running background processes with

shopt -s checkjobs

There is an option to send the SIGHUP on exit if you are in an interactive shell(see here). But it doesn't work on my machine with Bash 4.2.25. Maybe it works for you

shopt -s huponexit

Bash – Clarification for Bash documentation on disown builtin option -h

Without -h the job is removed from the table of active jobs, with -h it is not.

Everything is in the manual:

 disown [-ar] [-h] [jobspec ...]

       (...)
       If the -h option is given, each jobspec is not removed
       from the table, but is marked so that SIGHUP is not sent to the
       job  if  the shell  receives  a SIGHUP.

To see the difference run jobs after disowning the job with and without -h.

Best Answer

Related Solutions

SSH Signals – When SIGHUP is Not Sent to a Job on Logout

Bash – Clarification for Bash documentation on disown builtin option -h

Related Question