From owner-freebsd-current Tue Mar 25 16:52:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA27365 for current-outgoing; Tue, 25 Mar 1997 16:52:47 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA27358 for ; Tue, 25 Mar 1997 16:52:45 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA26494; Tue, 25 Mar 1997 17:38:48 -0700 From: Terry Lambert Message-Id: <199703260038.RAA26494@phaeton.artisoft.com> Subject: Re: 2.2R (src 2.2 211): == dialing To: bde@zeta.org.au (Bruce Evans) Date: Tue, 25 Mar 1997 17:38:48 -0700 (MST) Cc: bde@zeta.org.au, rb@gid.co.uk, freebsd-current@FreeBSD.ORG, joerg_wunsch@uriah.heep.sax.de, terry@lambert.org In-Reply-To: <199703252333.KAA16629@godzilla.zeta.org.au> from "Bruce Evans" at Mar 26, 97 10:33:32 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >>The slattach daemon has a controlling tty... > > > >Only until it calls daemon() immediately after cracking its args. > > No. It acquires a controlling tty a few lines after it becomes a > daemon, at least in the redial case (I think the !redial case is > still broken - it does a null redial instead of aborting like the > documentation for the -l option says it does). This means it should get a SIGHUP on on-to-off DCD transistion if -CLOCAL is set. Does it mean it should get SIGHUP when the tty is revoked? ...I don't think so, actually. There is a distingtion to be drawn between acquiring a controlling tty, and becoming a process group leader. Part of the problem here is how daemon(3) is supposed to work. It does not say that the process becomes a group or session leader, actually (this may just be a deficit in the man page; if so, it is arguable that the process should become a deamon by performing the explicit acts to become a daemon instead of making the library call with the process/session leadership side effects). You *could* argue, on this basis, that slattach is doing the wrong thing, and that's what's leaving it open to getting a SIGHUP when it should not be getting on. On the other hand, I believe other programs which call daemon(3) and do not reacquire a controlling tty also get the SIGHUP on shutdown, so no matter what, there is something rotten in Denmark... Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.