From owner-freebsd-hackers Thu Aug 26 19:18:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id E238F15474 for ; Thu, 26 Aug 1999 19:18:52 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.1/8.9.1) id TAA577882; Thu, 26 Aug 1999 19:18:48 -0700 Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp05.primenet.com, id smtpda2ZqMa; Thu Aug 26 19:18:35 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id TAA23170; Thu, 26 Aug 1999 19:18:33 -0700 (MST) From: Terry Lambert Message-Id: <199908270218.TAA23170@usr06.primenet.com> Subject: Re: dropped connections (fwd) To: nick.hibma@jrc.it Date: Fri, 27 Aug 1999 02:18:33 +0000 (GMT) Cc: barrett@phoenix.aye.net, fjoe@iclub.nsu.ru, hackers@FreeBSD.ORG In-Reply-To: from "Nick Hibma" at Aug 26, 99 04:36:06 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > ee does the same. The reason is that the program does not check for EOF > on stdin, it continuously loops. It's a bug in the program. The thing > that could have been changed is a signal from the shell that is no > longer sent or so. > > The problem is the program, not the OS. > > It might be wortwhile to find the problem, solve and send the patch to > the maintainer of the port and the original author. Unless the program is blocking SIGHUP, it is arguable that this is a misinterpretation of POSIX requirements for delivery of signals to process groups when controlling tty's are revoked by FreeBSD. I believe that it is a misinterpretation of what happens when a process group leader gets a SIGHUP, and its children themselves become group leaders on a device that has already been revoked (i.e. I believe it is an order of operation problem). Other POSIX compliant OS's do not have this problem, and SVR2, SVR3, Xenix 2.x, Xenix 3.x, Microport UNIX, ISC UNIX, Altos Xenix, Altos UNIX, UNICOS, HP/UX, SunOS, and Solaris all appear to disagree with FreeBSD (even though some are admittedly not POSIX compliant). Further, if a program is using non-blocking I/O, there does not appear to be a way for the program to distiguish between an EOF based failure, and one that results from a lack of available data on a valid descriptor. Please see POSIX 1003 or the "Go Solo 2" book for details on tty revocation. I also suggest reference to "The Magic Garden Explained" and "The Design and Implementation of the 4.3 BSD UNIX Operating System", in paticular, the section on both tty handling on on-to-off DCD transition for a tty on which modem control is enables, and on pty handling in the case that the master is closed. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message