Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!gatech!hubcap!ncrcae!ncr-sd!hp-sdd!hplabs!hp-ses!hpcea!hpausla!brianw
From: brianw@hpausla.HP.COM (Brian Wallis)
Newsgroups: comp.mail.elm
Subject: Re: newmail also displays on console (bug)
Message-ID: <890001@hpausla.HP.COM>
Date: 27 Feb 89 01:50:32 GMT
References: <316@wubios.wustl.edu>
Organization: HP Australian Software Operation
Lines: 63

/ hpausla:comp.mail.elm / syd@dsinc.UUCP (Syd Weinstein) /  2:54 am  Feb 24, 1989 /
In article <316@wubios.wustl.edu> david@wubios.wustl.edu (David J. Camp) writes:
...
> If you start newmail as newmail& and you use the c shell, newmail
> will not be killed when you logout as c shell will nohup it.
> 
> Thus when you log out, other users will still get the newmail output
> to the terminal.
> 
> How to get around this:
> Easy, when you configure elm, tell it that you always want newmail to
> run in the backround.  Then just start newmail as newmail without the
> & key.  It will fork it self, but still not be nohupped.  Then it will
> exit when you logout.
> 
> This is not an Elm bug.
...

In Elm 2.0 and 2.1, newmail with the AUTO_BACKGROUND option executes a
fork and the parent then exits. Under HP-UX 6.5 this gives a problem
since when the parent exits the child process's parent becomes init
(pid=1) so that when you logout, the newmail process is left running
(and writing to whatever terminal you were logged into).

try...

main()
{
	if(fork()){
		printf("parent exiting\r\n");
		sleep(20); /* makes no difference if this is here, was to
			      make sure child ran before parent exited */
		exit(0);
	}
	printf("child continuing\r\n");
	while(1){
		sleep(5);
		printf("hullo there\r\n");
	}
}

logging out will not kill this process! you have to explicitly kill it
yourself. This is defined HP-UX behaviour as in exit(2):-

          Exit is equivalent to _exit, except that exit flushes stdio
          buffers, while _exit does not. Both exit and _exit terminate
          the calling process with the following consequences:

.... (deleted stuff)

               The parent process ID of all of the calling process's
               existing child processes and zombie processes is set to
               1.  This means the initialization process (proc1)
               inherits each of these processes.

Is this normal *nix operation? I would have thought that the child
process's parent would be set to the parent of the exiting parent (do
I make my self obscure?)

Has anybody else noted this behaviour of newmail?

oh yeah, we are running newmail from .profile under ksh, but I've
tried sh and the same thing happens.