Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!think!mintaka!bloom-beacon!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.questions
Subject: Re: signal problems on BSD
Message-ID: <1990Mar12.032321.539@athena.mit.edu>
Date: 12 Mar 90 03:23:21 GMT
References: <34853@cci632.UUCP> <1990Mar6.070333.29327@athena.mit.edu> <5913@star.cs.vu.nl> <1990Mar8.084830.9252@athena.mit.edu> <5942@star.cs.vu.nl>
Sender: news@athena.mit.edu (News system)
Reply-To: jik@athena.mit.edu (Jonathan I. Kamens)
Organization: Massachusetts Institute of Technology
Lines: 56


  Well, I've looked in my kernel code, and I do, indeed, see code that
*should be* sending a HUP signal to the process group of the tty,
although I may certainly be reading something wrong, given that I have
limited experience with kernel hacking.

  I then compiled a new /bin/login for testing -- the new /bin/login
doesn't do anything with killpg(), because I'm trying to figure out if
the kernel does it automatically.

  I then compiled the following program, telnet'd into my workstation
(thus, I assume logging in on a pty), ran it in the background, and logged out:

    #include <syslog.h>
    #include <signal.h>

    report_it()
    {
         syslog(LOG_DEBUG, "Got a SIGHUP!");
         exit(0);
    }

	  
    main()
    {
         signal(SIGHUP, report_it);
         setpgrp(0, getpgrp(getppid()));
     
         for (;;)
              sigpause(0);
    }

Now, *if* the kernel sends a HUP when a pty is closed, then the program
should have received a HUP and exited when I logged out, right?  Well,
it didn't.  How come?

  When I put back our standard /bin/login with the killpg() statement in
it and do the same thing, the program does get a HUP when I log out.  So
what am I missing?

  One more thing -- I think that someone else asked earlier what the
point is of having /bin/login wait around while the user is logged in --
he said that if we take out the killpg() in /bin/login, we can just have
it exec() the login shell rather than waiting for the shell to finish.

  Well, unfortunately, we can't do that, because our /bin/login does
various other clean-up tasks after the user logs out (e.g. removing the
user's entry from the /etc/passwd file if he was added to the
/etc/passwd file when he logged in, and automatically destroying the
user's kerberos tickets).  Therefore, exec()'ing the login shell isn't
an option.

Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8495			      Home: 617-782-0710