Re: [Help-bash] Command run in the background (with '&' at the end) still runs even when the user exit from the login shell?

[Bob Proulx]

Chet Ramey wrote:
> Peng Yu wrote:
> > My previous impression was that processes run with '&' will be
> > automatically terminated once the user logs out. But I just checked
> > with the following example, it seems that these processes will
> > continue to run until finished.

I think what you are thinking of is the old Bourne shell behavior
without job control.

> Bash introduced the `huponexit' shell option in bash-2.02, which was
> released about 15 years ago.  Before that, it would only pass a SIGHUP
> it received through to its children (which it still does).  I don't
> know of any shells that killed background jobs at exit, but that doesn't
> mean the kernel didn't SIGHUP jobs with the same controlling terminal
> when a session leader exits.

This is from memory and I don't have time to verify it.  But I am
pretty sure this is true.  I recommend the Design and (BSD|Unix)
Operating System books for real information.  I am sure I have at
least something wrong.

Back in the days before BSD job control existed (before the 1980s?)
with the Bourne shell background jobs were in the same process group
as foreground processes.  SIGHUP in that case is sent to the
foreground process group.  Since background jobs were in the same
process group as foreground tasks all background jobs also got SIGHUP
at the same time.  Any jobs running in the background were killed
along with all of the rest of the process group.  (And so the utility
of nohup back then is apparent.  Nohup is less useful now that things
work differently.)

With the addition of BSD job control background jobs are launched in
their own process group.  This means that SIGHUP sent to the
foreground process group does not reach the background tasks running
in their own process group.  The background tasks don't get SIGHUP
sent to them these days.  And so the utility of huponexit in bash
becomes apparent.

One interesting case is what happens if there are stopped background
tasks at the time that the job control shell that is the controlling
process exits.  If nothing special is done then those stopped jobs
would remain stopped forever.  They have become an orphaned process.
This would create problems as those jobs would never be cleaned up.
Therefore the system keeps track of orphaned process groups and
orphaned processes within those groups.  If a process group become
orphaned then the process group is sent a SIGHUP and a SIGCONT which
usually kills those stopped jobs.  If the program ignores SIGHUP
(nohup or other) then the job can continue to run after becoming
orphaned when the controlling process exited.  Job control is useful
but it does make the model much more complex.

Basically the simple task model that everyone thinks they know about
SIGHUP and nohup applies to the old Bourne shell /bin/sh days before
job control.  This would have been documented as such in manuals
written sometime before 1985 or so but is in the culture because of it.

At one time only the csh had job control.  The sh did not and this was
one of the differences in behavior between them.  But as ksh and bash
and everything else has picked up job control, and the Bourne shell is
now quite hard to find, everything now behaves just like csh.

I think if you could find a real Bourne shell without job control and
try it then you would find that background jobs receive a SIGHUP and
exit when the shell exits.  I think.  It has been quite a few years
since I worked daily on a Bourne shell system without job control but
that is how I remember it.

Bob