Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cwjcc!gatech!hubcap!ncrcae!ncr-sd!hp-sdd!hplabs!hpda!hpcuhb!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: <890002@hpausla.HP.COM>
Date: 10 Mar 89 06:27:10 GMT
References: <316@wubios.wustl.edu>
Organization: HP Australian Software Operation
Lines: 72

/ hpausla:comp.mail.elm / cudcv@warwick.ac.uk (Rob McMahon) /  8:29 am  Mar  7, 1989 /
>In article <2918@epimass.EPI.COM> jbuck@epimass.EPI.COM (Joe Buck) writes:
>>In article <4774@pbhyf.PacBell.COM> rob@pbhyf.PacBell.COM (Rob$Bernardo) writes:
>>>Newmail already obeys SIGHUP. This particular user's environment is such that
>>>the SIGHUP is not being sent to newmail and that's the problem.
>>
>>This particular user's environment is quite common: under the Bourne shell,
>>background processes don't ingnore hangup unless you use the "nohup" command,
>>but under the C shell they do by default.
>
>No, this is the wrong problem, Rob Bernado was correct.  When you log out (at
>least Berkeley) Unix sends a SIGHUP to the process group of the terminal.  With
>the Bourne shell this means all processes run from that shell, because it does
>no process group manipulation.  The C-Shell, however, puts each `job' in it's
>own process group, so that the shell can manipulate who's allowed to talk to
>the terminal.  It does not cause SIGHUPs to be ignored when you background a
>job, it's just that the jobs never get a SIGHUP, because they're not in the
>process group of the terminal.  Presumably other shells with job control must
>do the same.

I believe that our problems began with HP-UX 6.5 which introduced
job control to ksh and csh. If I use shell, the process is killed
(gets the SIGHUP).

>
>>One solution is to define AUTO_BACKGROUND and have people run newmail without
>>doing ampersands.
>
>Right.

Wrong!
  As I mentioned (and gave an example) in an earlier RE: to this note
with AUTO_BACKGROUND defined the child forks, the parent exits and the
child process ends up being owned by init (1). With ksh it is NOT
killed (indeed, does not get a SIGHUP). Here is the simple example again!

main()
{
	if(fork()){
		printf("parent exiting\r\n");
		sleep(5);
		exit(0);
	}
	printf("child continuing\r\n");
	while(1){
		sleep(5);
		printf("hullo there\r\n");
	}
}

(this is basically what newmail does with AUTO_BACKGROUND defined)

The child process will NOT die when you log out and will continue to
write to the terminal until explicitly killed. I've tried setting the
process group of the child (setpgrp()) to the parent's parent process
group but I either stuffed it up or that doesn't work either.

>
>>Another is to explicitly catch SIGHUP instead of keeping the default behavior,
>>which, as you say, depends on the environment.
>
>No, the process never gets a SIGHUP.

It certainly doesn't, I tried it in the above example. So how do you
get rid of it!

>
>Rob

newmail still hangs around like a bad smell! 

Brian Wallis, ASO, Australia...