Subject: Re: Process gets SIGHUP at end of boot
To: Luke Mewburn <firstname.lastname@example.org>
From: Rick Byers <Rick@BigScaryChildren.net>
Date: 07/06/2001 16:13:08
On Fri, 6 Jul 2001, Rick Byers wrote:
> > I'm guessing that your problem occurs because the system boots using
> > /dev/console for the device for /etc/rc, and when init(8) goes into
> > state 3 to setup ttys, /etc/ttys has /dev/console being `off' and
> > /dev/ttyE0 (first wscons terminal) being `on', so the controlling
> > processes left on /dev/console (which might be the last thing
> > attached (???), in this case pppoe) get a SIGHUP.
> Could the shell (started for /etc/rc) be sending a SIGHUP to all child
> processes when it exits?
> Is there something going on with the terminal driver that I'm not aware
> of? Who else could be sending the SIGHUP?
I've done a bit of man-page reading (I've never been 100% clear on
sessions / process groups etc.). _exit(2) mentions that if a "controlling
process" exits, SIGHUP is sent to the fg process group of the terminal.
When init execs sh, it first calls "setctty" to start a new session and
allocate a controlling terminal for it, so the sh process becomes the
controlling process. This explains why everything in sh's process group
get a SIGHUP when sh exits.
However, both pppoe and mysqld are background processes and so have their
own process group, so this shouldn't be the problem (an examination of
kern_exit.c confirms that the signal is only deliverd to the forground
process group, not the whole session).
_exit(2) also mentions that if a process group is orphaned AND a member of
the group is stopped - SIGCONT and SIGHUP are sent to all members of the
group. Is this correct? Or should it say something like "if a group is
orphaned, SIGHUP is sent to all members and SIGCONT is sent to any which
are stopped"? I don't think its the latter case because if I exit a shell
which I started a background shell script from (i.e. orphaning the process
group of the shell script), the shell script doesn't get a SIGHUP.
It must be something along theese lines, but I'm still not sure exactly
what. Any insights?
Would it make sense just to run the seperate background shell scripts in
their own session? I.e. create a utility similar to nohup but that calls
setsid instead of just ignoring sighup?