From owner-freebsd-stable  Wed Apr  8 06:50:46 1998
Return-Path: <owner-freebsd-stable@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id GAA04477
          for freebsd-stable-outgoing; Wed, 8 Apr 1998 06:50:46 -0700 (PDT)
          (envelope-from owner-freebsd-stable@FreeBSD.ORG)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA04364;
          Wed, 8 Apr 1998 06:50:21 -0700 (PDT)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id XAA25552;
	Wed, 8 Apr 1998 23:46:15 +1000
Date: Wed, 8 Apr 1998 23:46:15 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199804081346.XAA25552@godzilla.zeta.org.au>
To: bde@zeta.org.au, eirvine@tpgi.com.au, freebsd-stable@FreeBSD.ORG
Subject: Re: A new Bug with FreeBSD?
Cc: ache@FreeBSD.ORG
Sender: owner-freebsd-stable@FreeBSD.ORG
Precedence: bulk

>>I presume this shouldn't happen on a Unix system -
>>all processes should be children of the logged in
>>user, and thus should get KILL'ed when the user
>>exits, no matter how they exit.

I wrote:
>Not in POSIX.1-1990.  Killing is associated with exit() of controlling
>processes (telnet in this case).  SIGHUP is sent to each process in the
            actually $SHELL
>_foreground_ process group of the controlling terminal of the controlling
>process, and if exit of the controlling process causes a process group
>to become orphaned and any member in the newly orphaned process group is
>stopped, than a SIGHUP followed by a SIGCONT is sent to every process in
>the newly orphaned process group here.  I'm not sure of the details here,
>but this normally results in propagation of SIGHUP being limited to one
>or two levels of the process tree - shells propagate it, but mail programs
>don't.  Death of the controlling terminal results in reads on the c.t.
>returning -1/EIO (the more usual 0 is not returned due to a kernel bug),
>and interactive processes should exit when they read -1 or 0 on stdin
>or /dev/tty.  libncurses has perfectly broken handling of both types of
>EOF, so programs that use it usually spin when the controlling terminal
>goes away.

The bug is easier to demonstrate and the process groups are easier to
follow using just $SHELL, mail and ee.  Just run mail and invoke the
editor; then kill the shell using another login.  Before the shell is
killed, `ps j -t vN' gives something like:

USER   PID  PPID  PGID   SESS JOBC STAT  TT       TIME COMMAND
bde    190     1   190 6fcf80    0 Is    v1    0:00.22 -bash (bash)
bde    460   190   460 6fcf80    1 I+    v1    0:00.02 mail
bde    461   460   460 6fcf80    1 I+    v1    0:00.10 ee /tmp/ReCnm460

The foreground process group is 460, and ee is in it, so sending a SIGHUP
to the foreground process group should work.  However, killing the shell
gives something like:

USER   PID  PPID  PGID   SESS JOBC STAT  TT       TIME COMMAND
bde    461     1   460 6fcf80    0 R     v1-   0:17.20 ee /tmp/ReCnm460
root   485     1   485 746e00    0 Ss+   v1    0:00.02 /usr/libexec/getty Pc tt

ee ignores SIGHUP:

---
int
main(argc, argv)		/* beginning of main program		*/
int argc;
char *argv[];
{
	int counter;

	for (counter = 1; counter < 24; counter++)
		signal(counter, SIG_IGN);
---

There are almost 24 bugs here (one for each signal ignored).  Some
signals are handled better later, but SIGHUP isn't, and even if it
were, an early SIGHUP would be lost.

Bruce

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message