signal problems on BSD
Jonathan I. Kamens
jik at athena.mit.edu
Mon Mar 12 13:23:21 AEST 1990
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 at Athena.MIT.EDU Allston, MA 02134
Office: 617-253-8495 Home: 617-782-0710
More information about the Comp.unix.questions
mailing list