mp@allegra.UUCP (Mark Plotnick) (11/08/84)
rlogind sends a signal 9 to all processes in the user's login process
group when the user logs out. If the user uses /bin/sh, then the
user's entire process tree, including background uucico's and sendmail's,
gets creamed. This is less than optimal. Is there any reason why
the following wouldn't work?
- in rlogind.c, change kill(0, SIGTERM) to kill(0, SIGHUP)
- in login.c, add a signal(SIGHUP,SIG_DFL) before the user's
login shell is invoked. This is necessary because getty's and
login's that are invoked from daemons (such as rlogind and chserver)
apparently have SIGHUP ignored.
Mark Plotnick
Society for the Prevention of Cruelty to Processesmp@allegra.UUCP (Mark Plotnick) (11/08/84)
I meant to say SIGKILL instead of SIGTERM in the previous article. Mark
jim@haring.UUCP (11/16/84)
> - in login.c, add a signal(SIGHUP,SIG_DFL) before the user's > login shell is invoked. This is necessary because getty's and > login's that are invoked from daemons (such as rlogind and chserver) > apparently have SIGHUP ignored. > Mark Plotnick > Society for the Prevention of Cruelty to Processes This interested me, as I could find no justification for it. However, things became clearer when I realised that we are running two different versions of /etc/inetd (the Internet super-server) on our systems, an old one from SUN and a new one from Berkeley. Daemons spawned by the new one do not have SIGHUP ignored, but the old ones do. This is because the new inetd has a SIGHUP catch routine, whereas the old one doesn't and just inherits it from its parent (/etc/init). This lead me to the discovery that anything spawned from /etc/rc has SIGHUP ignored, due to the routine 'shutdown' in /etc/init being called right at the beginning, which sets SIGHUP. Now, the question is, is this intentional? If it is, then the processes spawned by /etc/rc should take note of it, if it isn't, then /etc/init should be fixed. Jim McKie Centrum voor Wiskunde en Informatica, Amsterdam mcvax!jim