Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!pasteur!ames!lll-winken!uunet!mcvax!ukc!dcl-cs!aber-cs!pcg
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: comp.mail.elm
Subject: Re: newmail also displays on console (bug)
Summary: Enough! SIGHUP ought to kill it.
Message-ID: <771@aber-cs.UUCP>
Date: 15 Mar 89 13:57:39 GMT
Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Distribution: eunet,world
Organization: Dept of CS, UCW Aberystwyth
	(Disclaimer: my statements are purely personal)
Lines: 62

In article <192@cctb.mn.org> randy@cctb.mn.org (Randy Orrison) writes:

    In article <7310001@hpscdc.HP.COM> schmitz@hpscdc.HP.COM (John Schmitz) writes:
    > Re: newmail not going away:
    > Would it also be possible to record the id of the parent's shell and
    > do a kill(parent_id, 0) to detect the parent shell going away?
    
    Why not just do a getppid() when it starts, record that, and if it ever
    changes, exit()? I don't have my man pages handy, but I would be very
    surprised if getppid() returned the old parent pid after it had exited,
    in any version.

Not everybody has getppid()...

    This would also work in braindamaged configurations
    where the process doesn't get a SIGHUP for some reason. 

Let us review the problem, that has already been discussed: on a true to
life UNIX, when you log out, a SIGHUP signal is sent to all processes in the
same process/tty group as the terminating shell. This ought to terminate
newmail (and monthd, and whatever other daemons you have).

If your various processes do not terminate on logout, it is because either:

Your processes are no longer in the same process/tty group as the shell

    This happens easily. Especially with the C shell, that puts background
    jobs in their own group so that it can implement certain aspects of
    job control. It may also be that many programs do establish themselves
    as a new group leader with setpgrp(2). On System V ystems, or with
    the Bourne shell, this normally does not happen.

    There are certain (buggy) systems that do not signal SIGHUP on logout,
    e.g. they only signal SIGHUP if the carrier does drop, which of course
    does not normally happen on local terminals.

Your processes no longer have SIGDFLT (die) for SIGHUP

    This used to be the case only if you prefixed the command line with
    "nohup", precisely to avoid the prefixed command line being killed
    when you logged out. Again, the C shell nohup's by default all
    background jobs, even if on the other hand, it does not let you
    logout if there are any pending.

Solutions

Check carefully the manual pages of your shell to see what it does to
processes, whether it puts them in their own processes group, and whether it
makes them ignore SIGHUP, and other which circumstances, and the system
manual pages, on whether SIGHUP gets sent to a dying shell process group,
and under what circumstances.

Somebody has said that making newmail fork itself and then having the parent
terminate works; if you use the C shell, this makes you detach a process
without using "&", so that the C shell will not create a job environment
for you, and the detached newmail will be in the same process group and
will not have been nohup'ed. But there is no guarantee that it will work
for all combinations of shell and system and machine type... Too bad.
-- 
Piercarlo "Peter" Grandi            |  ARPA: pcg%cs.aber.ac.uk@nss.cs.ucl.ac.uk
Dept of CS, UCW Aberystwyth         |  UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK  |  INET: pcg@cs.aber.ac.uk