From owner-freebsd-hackers Sat Mar 30 00:38:54 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA22833 for hackers-outgoing; Sat, 30 Mar 1996 00:38:54 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA22828 for ; Sat, 30 Mar 1996 00:38:52 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id BAA07024; Sat, 30 Mar 1996 01:35:55 -0700 From: Terry Lambert Message-Id: <199603300835.BAA07024@phaeton.artisoft.com> Subject: Re: Help, processes not getting killed when users exit To: mbarkah@hemi.com (Ade Barkah) Date: Sat, 30 Mar 1996 01:35:55 -0700 (MST) Cc: hackers@FreeBSD.org In-Reply-To: <199603300601.XAA11875@hemi.com> from "Ade Barkah" at Mar 29, 96 11:01:37 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > [I'm using FreeBSD 2.1-R] > > I've noticed that some of my processes aren't getting killed when > the connection is broken, and I've been trying to figure out why > this is. Some of the programs which (sometimes) stay alive include > 'vi' and 'irc'... they go into a loop trying to perform I/O on > the pty and drive up CPU usage like mad (they don't seem to check > the result of their read() calls.) > > Suppose a remote telnet connection disconnects. Telnetd notices > it, calls cleanup(), and exits. How do the shell and the application > get notified ? I.e., which process is responsible in sending a > SIGHUP to the user's processes ? When the telnetd exits, it closes the master size of the pty (the shell and any user apps are running on the slave side). When this happens, if the slave side is set HUPCL, then a SIGHUP is sent to the controlling process. If this process is group leader (it is), then it is supposed to send SIGHUP to all processes in the process group (it doesn't do that because the wording of POSIX is vague in this regard as to order of delivery vs. where default handling occurs: in the process or in the kernel). What happens instead on BSD, is that the close of the master causes a "revoke". Processes that don't trap read returns for EOF will go into a tight loop; those that do, will exit, just like if BSD had properly delivered the SIGHUP to the child processes (like POSIX implies you shouldn't, and like SunOS, Solaris, HPUX, SCO, Linux, BSDI, Ultrix, OSF/1, SVR3, SVR4, and AIX all do...). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.