Hello Perry.  Well, I've played more with this problem and it seems to
be worse than I originally thought.  Specifically, if I log into a NetBSD
machine through a hardware serial connection, start the window program, shut
it down, logout of the serial port, login as a different user on the same
port, start the window program in that new session, I get access to all of
the first user's shells under the window program.
	So, the problem seems to have to do with how access to the terminal
gets revoked when the window process terminates.  Since it works fine on a
pty, via telnet, and I can confirm that all of the proper signals are
getting sent through the pty, I can only conclude that the sigHUP isn't
getting sent to thetpgid of the terminal, or, that the child can't get
signals off to the process groups it manages.  I'm trying to absorb the
4.4BSD book to understand what's going on here, but it's slow going.  In
the interest of security, I'd like to point this out as a followup to
pr/7499.  
-Brian



                          NETBSD PROBLEM REPORT #7499
                                       

  by redmail.netbsd.org with SMTP; 29 Apr 1999 21:12:40 -0000
          by cats.ucsc.edu (8.8.6/8.8.4.cats-athena) with ESMTP
          id OAA05116 for <gnats-bugs@gnats.netbsd.org>; Thu, 29 Apr 1999 14:12
:41 -0700 (PDT)
        by baloo.ucsc.edu (8.8.6/8.8.8.cats-client) id OAA06088
        for gnats-bugs@gnats.netbsd.org; Thu, 29 Apr 1999 14:12:36 -0700 (PDT)
Message-Id: <199904292112.OAA06088@baloo.ucsc.edu>
Date: Thu, 29 Apr 1999 14:12:36 -0700 (PDT)
From: buhrow@cats.ucsc.edu (Brian Buhrow)
Reply-To: buhrow@cats.ucsc.edu
To: gnats-bugs@gnats.netbsd.org
Cc: buhrow@cats.ucsc.edu
Subject: Problem with serial terminals and persistent children processes


>Number:         7499
>Category:       kern
>Synopsis:       Subshells of the window program do not receive SIGHUP when win
dow exits.
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Apr 29 14:20:00 1999
>Originator:     Brian Buhrow
>Organization:
        UC Santa Cruz
>Release:        NetBSD-current April 16, 1999
>Environment:
System: NetBSD glorfindel.nfbcal.org 1.4_ALPHA NetBSD 1.4_ALPHA (GLORFINDEL) #2
: Fri Apr 16 12:13:16 PDT 1999 buhrow@glorfindel.nfbcal.org:/usr/src/sys/arch/i
386/compile/GLORFINDEL i386




>Description:
        <precise description of the problem (multiple lines)>
        If the window program, shipped with the distribution, is invoked from
a serial terminal session, i.e. through a hardware serial port, when the
window program exits, the shells it spawned in the various windows, along
with any processes they spawn, do not receive a SIGHUP signal.  They are
supposed to receive a SIGHUP signal when window exits, and this does work
when logging in through a telnet connection and a pseudo terminal.  As a
result, the user of the window program leaves a bunch of orfaned processes
on the system when he or she logs out unless he or she kills them manually
by sending a SIGHUP with the kill(1) program.
        This functionality worked in NetBSD 0.9, 1.0, 1.1 and 1.2, I haven't
been able to test 1.3, but my suspicion is that it works there as well.
I'm not sure where the problem is precisely, but I suspect that it is a
problem with the interaction of the com driver and the tty layer.  The i386
binary snapshot of March 15, 1999 shows the same behavior as the sources I
used April 16, 1999.  The versions of the com and kern_tty files are as
follows:
/usr/src/sys/kern/tty.c:
     $NetBSD: tty.c,v 1.112 1998/09/11 12:50:11 mycroft Exp $
/usr/src/sys/dev/ic/com.c:
     $NetBSD: com.c,v 1.159 1999/03/31 12:44:04 mrg Exp $


>How-To-Repeat:
        Activate a getty process on a serial port.


        Use a terminal or terminal emulator to login through that serial port.
(I don't know if kermit through two separate serial ports on the same
computer would be a good test.)


        Once you have a shell, install the enclosed .windowrc file in your
home directory as  ~/.windowrc.


        Launch the window program.
%window -e^o


Determine the process id for one of the shells in one of the windows that
result.
^o3
[3]%tty
/dev/ttyp2
^o1
[1]%ps -uxw |grep 'p2
[1]%cd /var/tmp
[1]%ktrace -p [pid found above]
[1]%ls -l ktrace.out
-rw------ 1 [user] 50 Apr 28 15:50 ktrace.out
[1]%
^oq [Really quit? [yn]: y]
%cd /var/tmp


%ls -l ktrace.out
-rw------ 1 [user] 50 Apr 28 15:50 ktrace.out


        If the size of the file is unchanged, then the shell is still running
and has not received its SIGHUP signal.  Otherwise, it will be about 495
bytes or so and will have exited.  The ^o syntax above indicates a command
to the window program itself and means issue a control-o.  The brackets
indicate which window you're working in.  The non-bracketed prompts
indicate you're working in the raw tty session.
        Here is the .windowrc file I use and have used since window ran on
Vaxen under 4.3BSD.


nline 1000
window(1,0,11,80)
window(13,0,11,80)
window(1,0,11,80)
window(13,0,11,80)
window(1,0,11,80)
window(13,0,11,80)
window(1,0,11,80)
window(13,0,11,80)
window(1,0,23,80)
select 1


>Fix:
        I don't know how to work around this problem at this time.
>Audit-Trail:
>Unformatted:


>Last-Modified:


   
     _________________________________________________________________
   
   NetBSD Problem Database Query Form
     _________________________________________________________________
   
   NetBSD Home Page
     _________________________________________________________________
   
   
    www@NetBSD.ORG
    $NetBSD: query-full-pr,v 1.19 1998/07/18 05:53:54 mycroft Exp $
    $NetBSD: gnats_config.sh,v 1.4 1996/06/14 19:52:34 thorpej Exp $
    Copyright (c) 1996 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.