Date: Tue, 25 Mar 1997 16:28:34 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: rb@gid.co.uk (Bob Bishop) Cc: bde@zeta.org.au, freebsd-current@FreeBSD.org, joerg_wunsch@uriah.heep.sax.de, terry@lambert.org Subject: Re: 2.2R (src 2.2 211): <ctrl><alt><del> == dialing Message-ID: <199703252328.QAA26225@phaeton.artisoft.com> In-Reply-To: <l03020908af5e07f22ef7@[194.32.164.2]> from "Bob Bishop" at Mar 25, 97 11:00:54 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >The slattach daemon has a controlling tty... > > Only until it calls daemon() immediately after cracking its args. > > >... but shouldn't be sent a SIGHUP, since that > >tells it to redial. > > Which is (close to) where we came in. No, this is far from it. The controlling tty for the slattach is a result of the tty for the connection being the first open after the process has orphanned itself from a controlling tty. I think the problem here is that the session and process group are being treated incorrectly. It should be possible to distinguish a process which has made a tty it's controlling tty in order to get device events as signals, and a process which has a controlling tty because it is interactive. This cuts to the heart of the session vs. process group leader distinction, and the idea of whether a process which is the sole process on a tty must be considered the group leader. If you think that it should, then you are arguing with me for the SVR4 behaviour of the process group leader propagating SIGHUP to its children. This is a necessary condition of this treatment of group. > >I think ignoring SIGTERM is braindamaged. > > AFAIK, interactive shells have always done so (since V7 at least). > Bear in mind that SIGHUP originated historically as a (hardware) > indication that carrier had dropped because the caller had Hung UP, > whereas TERM has always been a pure software signal. SIGHUP is actually on-to-off DCD transition notification for a process for which the tty is the controlling tty and for which the tty modes specify -CLOCAL (the connection is non-local and therefore modem control signals should be obeyed). The error is in not distinguishing a sole process on a tty from a group leader by virtue of whether or not it is a tty it has claimed, and whether the tty is the tty which the process originally had before it was daemonized. Daemons, of course, don't get SIGHUP from init. The SIGHUP in this case should originate not because the signal was explicitly sent, but because the tty was revoked, and processes which are group leaders get SIGHUP when a tty which is a controlling tty for the process is revoked. Probably, the sltattch should not be being considered a group leader. Note that this exempts processes without a controlling tty (generally, any process which uses a SIGHUP to signal a reset -- like init, named, and so on) from getting a SIGHUP. If the SIGHUP result from the revoke (the process is a group leader) or from a group resend (the group send in the kernel should cause all children of the leader to be sent a SIGHUP before they are orphaned, and then when they are orphaned, it will be processed), then the daemons will never get it. After the delay, then sending the SIGINT to remaining processes is the correct thing to do, regardles of their group membership; the same goes for SIGKILL. I'm not sure whether SIGTERM should ever be sent, actually... I guess it can't hurt, considering it's default is to terminate the process. ...Though I rather suspect that more programs have SIGINT handlers than SIGTERM handlers, so sending SIGTERM with a default of terminal process will actually *prevent* these programs from gracefully saving state and shutting down. 8-(. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703252328.QAA26225>