david@wubios.wustl.edu (David J. Camp) (02/22/89)
The newmail program displays its output not only on the users terminal, but on the system console, for all users using newmail. They do not need to be logged in on the console for this to happen. We consider this a security/privacy violation. We are using a Sun 3/260 running SunOS 4.0.1. -David- -- Bitnet: david@wubios.wustl ^ Mr. David J. Camp Internet: david%wubios@wucs1.wustl.edu < * > Box 8067, Biostatistics uucp: uunet!wucs1!wubios!david v 660 South Euclid Washington University Medical School Saint Louis, MO 63110
syd@dsinc.UUCP (Syd Weinstein) (02/23/89)
In article <316@wubios.wustl.edu> david@wubios.wustl.edu (David J. Camp) writes: >The newmail program displays its output not only on the users terminal, >but on the system console, for all users using newmail. They do not >need to be logged in on the console for this to happen. We consider >this a security/privacy violation. We are using a Sun 3/260 running >SunOS 4.0.1. If you use c shell (csh), be aware that it starts backround jobs with nohup. 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. -- ===================================================================== Sydney S. Weinstein, CDP, CCP Elm Coordinator Datacomp Systems, Inc. Voice: (215) 947-9900 {allegra,bpa,vu-vlsi}!dsinc!syd FAX: (215) 938-0235
rob@pbhyf.PacBell.COM (Rob Bernardo) (02/25/89)
In article <316@wubios.wustl.edu> david@wubios.wustl.edu (David J. Camp) writes:
+The newmail program displays its output not only on the users terminal,
+but on the system console, for all users using newmail. They do not
+need to be logged in on the console for this to happen. We consider
+this a security/privacy violation. We are using a Sun 3/260 running
+SunOS 4.0.1.
I have been using newmail extensively and have not experienced this at all.
What is strange is that the word "console" does not appear in the source
for newmail at all.
--
Rob Bernardo, Pacific Bell UNIX/C Reusable Code Library
Email: ...![backbone]!pacbell!pbhyf!rob OR rob@pbhyf.PacBell.COM
Office: (415) 823-2417 Room 4E850O San Ramon Valley Administrative Center
Residence: (415) 827-4301 R Bar JB, Concord, Californiabrianw@hpausla.HP.COM (Brian Wallis) (02/27/89)
/ 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.
rob@pbhyf.PacBell.COM (Rob Bernardo) (02/28/89)
In article <890001@hpausla.HP.COM> brianw@hpausla.HP.COM (Brian Wallis) writes:
+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).
...
+logging out will not kill this process! you have to explicitly kill it
+yourself. This is defined HP-UX behaviour as in exit(2):-
[quotes manual how init inherits processes that "lose" their parent process.]
...
+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?)
Yes, but you forgot one thing, and maybe this is what's not happening
on some systems. When you log out a SIGHUP signal is supposed to be
sent to all processes in the process group, which should include your
newmail in the background. SIGHUP will kill newmail. Now it could
be that someone set your login ports to default to "no hang up on
last close" (see stty(1)), which I'd say is bad practice. It interferes
with the proper way of killing processes if your login connection
should accidentally drop (as in hardware probelm or hung up phone
line.) See your sys admin about that.
--
Rob Bernardo, Pacific Bell UNIX/C Reusable Code Library
Email: ...![backbone]!pacbell!pbhyf!rob OR rob@pbhyf.PacBell.COM
Office: (415) 823-2417 Room 4E850O San Ramon Valley Administrative Center
Residence: (415) 827-4301 R Bar JB, Concord, Californiazeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (02/28/89)
>> 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. >> This is not an Elm bug. Since we can easily predict that people WILL do this, I say it's a problem that should be fixed. Why not just set SIGHUP to be sure it gets killed? -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Ann Arbor, MI mailrus!b-tech!zeeff
rob@pbhyf.PacBell.COM (Rob Bernardo) (03/01/89)
In article <5142@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) 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.
+>> This is not an Elm bug.
+Since we can easily predict that people WILL do this, I say it's a problem
+that should be fixed. Why not just set SIGHUP to be sure it gets killed?
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.
--
Rob Bernardo, Pacific Bell UNIX/C Reusable Code Library
Email: ...![backbone]!pacbell!pbhyf!rob OR rob@pbhyf.PacBell.COM
Office: (415) 823-2417 Room 4E850O San Ramon Valley Administrative Center
Residence: (415) 827-4301 R Bar JB, Concord, Californiazeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (03/01/89)
>+>> 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. >+Since we can easily predict that people WILL do this, I say it's a problem >+that should be fixed. Why not just set SIGHUP to be sure it gets killed? > >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. No, newmail does NOT set things to die on SIGHUP - it leaves the SIGHUP action in the same state it was when it was run. Try adding signal(SIG_HUP,SIG_DFL); if you want it to die even if someone uses & from csh. -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Ann Arbor, MI mailrus!b-tech!zeeff ----- Use lint! -----
jbuck@epimass.EPI.COM (Joe Buck) (03/02/89)
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. One solution is to define AUTO_BACKGROUND and have people run newmail without doing ampersands. Another is to explicitly catch SIGHUP instead of keeping the default behavior, which, as you say, depends on the environment. -- -- Joe Buck jbuck@epimass.epi.com, uunet!epimass.epi.com!jbuck If you're not annoying somebody, you're not really alive. - Margaret Atwood
cudcv@warwick.ac.uk (Rob McMahon) (03/07/89)
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. >One solution is to define AUTO_BACKGROUND and have people run newmail without >doing ampersands. Right. >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. Rob -- UUCP: ...!mcvax!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick ARPA: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (03/08/89)
>>>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. Old versions of newmail didn't set things up to die on SIGHUP. New ones will. >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. Not on this system (sys V.3). SIGHUPS _are_ ignored on csh & jobs and a program must change it if it wants otherwise. SIGHUPS _are_ sent when you log out. You may be correct about systems with job control but it seems like a major problem. You're saying that SIGHUP is often worthless on such a system. -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Ann Arbor, MI mailrus!b-tech!zeeff
david@wubios.wustl.edu (David J. Camp) (03/10/89)
> >>One solution is to define AUTO_BACKGROUND and have people run newmail without >>doing ampersands. > >Right. > We have AUTO_BACKGROUND defined, run newmail from csh without an ampersand, and it still is not killed WHEN IT WAS RUN FROM THE CONSOLE. I have studied the code in newmail.c, and I do not see how the process put in the background is automatically killed upon logout. Perhaps someone in-the-know can explain to me how this is done. -David- -- Bitnet: david@wubios.wustl ^ Mr. David J. Camp Internet: david%wubios@wucs1.wustl.edu < * > Box 8067, Biostatistics uucp: uunet!wucs1!wubios!david v 660 South Euclid Washington University Medical School Saint Louis, MO 63110
schmitz@hpscdc.HP.COM (John Schmitz) (03/10/89)
Re: newmail not going away: >>One solution is to define AUTO_BACKGROUND and have people run newmail without >>doing ampersands. > > Right. 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? You'd have the small problem of process id rollover, but I bet that's a rare occurrence (anybody know a good way around this?).
brianw@hpausla.HP.COM (Brian Wallis) (03/10/89)
/ 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...
syd@dsinc.UUCP (Syd Weinstein) (03/12/89)
In article <330@wubios.wustl.edu> david@wubios.UUCP (David J. Camp) writes:
:We have AUTO_BACKGROUND defined, run newmail from csh without an
:ampersand, and it still is not killed WHEN IT WAS RUN FROM THE CONSOLE.
:
:I have studied the code in newmail.c, and I do not see how the process
:put in the background is automatically killed upon logout. Perhaps
:someone in-the-know can explain to me how this is done.
It's really very simple. We do nothing, and when the init process
sends a SIGHUP, we take the default action, to die.
--
=====================================================================
Sydney S. Weinstein, CDP, CCP Elm Coordinator
Datacomp Systems, Inc. Voice: (215) 947-9900
{allegra,bpa,vu-vlsi}!dsinc!syd FAX: (215) 938-0235syd@dsinc.UUCP (Syd Weinstein) (03/12/89)
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? Not all Unix's support the concept of kill(parent_id, 0) to detect if the parent is still around. This solution is not universal. In fact, a program would have to be written to check, at configure time whether this option is supported. All we have done in 2.2, is reconnect SIGHUP if it was disconnected by the parent. However, this still depends on newmail being in the same process group as the parent. It won't solve all the problems, but will help with some. -- ===================================================================== Sydney S. Weinstein, CDP, CCP Elm Coordinator Datacomp Systems, Inc. Voice: (215) 947-9900 {allegra,bpa,vu-vlsi}!dsinc!syd FAX: (215) 938-0235
randy@cctb.mn.org (Randy Orrison) (03/13/89)
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. This would also work in braindamaged configurations where the process doesn't get a SIGHUP for some reason. -randy -- Randy Orrison - Chemical Computer Thinking Battery - randy@cctb.mn.org (aka randy@{umn-cs.uucp, ux.acss.umn.edu, umnacvx.bitnet, garnet.uucp}) "Blow a lawyer to pieces / It's the obvious way Don't wait for a thesis / Do it today" - Al Stewart
pcg@aber-cs.UUCP (Piercarlo Grandi) (03/15/89)
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
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (03/16/89)
The summary on this discussion is that there are two different problems being talked about. The next release of newmail has a modification so that newmail run from csh with "newmail &" will die when you logout on systems without job control. For systems with csh and job control, you could use the new newmail and put "/bin/kill -1 -1" in .logout. This probably has bad effects for root and if you are logged in more than once. Code for a better solution would be welcomed. -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Ann Arbor, MI mailrus!b-tech!zeeff
brianw@hpausla.HP.COM (Brian Wallis) (03/16/89)
> / hpausla:comp.mail.elm / randy@cctb.mn.org (Randy Orrison) / 3:17 pm Mar 13, 1989 / > 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. This would also work in braindamaged configurations > where the process doesn't get a SIGHUP for some reason. This won't work when you use AUTO_BACKGROUND as we do, and in 2.1 version this is done if AUTO_BACKGROUND is not defined, actually it checks if getppid() returns 1, ie. init is parent. I changed it so that the parent gets it's parent's pid and then the child checks if it's parent's parent still exists using 'getpgrp2(pid)' which fails if the process no longer exists or is not of the same uid. I know, there is a very small hole there, but who cares? I don't. Here are the diffs for my version RCS file: RCS/newmail.c,v retrieving revision 2.1 rdiff -c -r2.1 newmail.c *** /tmp/,RCSt1a26904 Thu Mar 16 13:55:11 1989 --- newmail.c Thu Mar 16 11:34:46 1989 *************** *** 135,140 long lastsize, newsize; /* file size for comparison.. */ interval_time = DEFAULT_INTERVAL; opterr = 0; --- 135,144 ----- long lastsize, newsize; /* file size for comparison.. */ + #ifdef AUTO_BACKGROUND + int ppid=getppid(); /* parent's pid, probably a shell */ + #endif + interval_time = DEFAULT_INTERVAL; opterr = 0; *************** *** 179,185 #ifdef AUTO_BACKGROUND if (! in_window) { if (fork()) /* automatically puts this task in background! */ ! exit(0); signal(SIGINT, SIG_IGN); signal(SIGQUIT, SIG_IGN); --- 183,189 ----- #ifdef AUTO_BACKGROUND if (! in_window) { if (fork()) /* automatically puts this task in background! */ ! exit(0); /* and the parent exits */ signal(SIGINT, SIG_IGN); signal(SIGQUIT, SIG_IGN); *************** *** 194,199 #ifndef AUTO_BACKGROUND /* won't work if we're nested this deep! */ if (getppid() == 1) /* we've lost our shell! */ exit(); #endif if (! isatty(1)) /* we're not sending output to a tty any more */ exit(); --- 198,214 ----- #ifndef AUTO_BACKGROUND /* won't work if we're nested this deep! */ if (getppid() == 1) /* we've lost our shell! */ exit(); + #else + /* + do a getpgrp2() on our parent's parent. This was where we were started + from originally before AUTO_BACKGROUNDing, so if it goes away (and this + call returns an error) we can exit. It is possible that the process id + in ppid is a valid process again, but it is unlikely that it is ours. + Bad luck if it is! (life wasn't meant to be easy!) + */ + if (getpgrp2(ppid) == -1){ /* parent's parent has gone away! */ + exit(); + } #endif if (! isatty(1)) /* we're not sending output to a tty any more */ exit();
cudcv@warwick.ac.uk (Rob McMahon) (03/18/89)
Re: background jobs not receiving SIGHUP on systems with job control. In article <9079@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >You may be correct about systems with job control but it seems like a major >problem. You're saying that SIGHUP is often worthless on such a system. I failed to say that the current foreground job, and the shell, still receive the SIGHUP, so SIGHUP still does it's job of clearing the terminal. I guess it depends on what you expect SIGHUP to do ... it feels like a feature to me that a job I've put into the background doesn't get killed when I unexpectedly get called away, just because I've forgotten to use `nohup' on it. Rob -- UUCP: ...!mcvax!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick ARPA: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England
cudcv@warwick.ac.uk (Rob McMahon) (03/18/89)
I'm cross-posting this to comp.unix.wizards, and sending follow-ups there, since this has stopped being an elm question. I'll report back here if no-one else does. In article <91@dsinc.UUCP> syd@dsinc.UUCP (Syd Weinstein) writes: >In article <330@wubios.wustl.edu> david@wubios.UUCP (David J. Camp) writes: >:I have studied the code in newmail.c, and I do not see how the process put >:in the background is automatically killed upon logout. Perhaps someone >:in-the-know can explain to me how this is done. > >It's really very simple. We do nothing, and when the init process sends a >SIGHUP, we take the default action, to die. [But processes not in the process group of the terminal on systems with job control never see the SIGHUP] This is quite an interesting problem really. If the background process does not fork, it can check getppid() occasionally, when it returns 1 it knows it has been orphaned and can exit. If it does fork things gets more tricky. It can try to kill(shell_pid, 0), but a) not all systems allow this, and b) there's a chance of pid reuse. The BSD `leave' program uses getlogin() and compares it against a stashed copy. At least this means that the only person it's going to annoy is yourself. Anyone got any better ideas on how a process which forks and carries on running in the background can detect when the original shell has gone away ? Rob -- UUCP: ...!mcvax!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick ARPA: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England
cudcv@warwick.ac.uk (Rob McMahon) (03/24/89)
In article <9120@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >For systems with csh and job control, you could use the new newmail and put >"/bin/kill -1 -1" in .logout. This probably has bad effects for root and if >you are logged in more than once. Code for a better solution would be >welcomed. ... and if you've got any background jobs you want to survive. Nobody yet seems to have suggested a better method than to stash a copy of getlogin() away when you start up, and to compare that with the current value just before checking for mail, exiting if they don't match. Rob -- UUCP: ...!mcvax!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick ARPA: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England
cudcv@warwick.ac.uk (Rob McMahon) (03/25/89)
In article <890003@hpausla.HP.COM> brianw@hpausla.HP.COM (Brian Wallis) writes: >I changed it so that the parent gets it's parent's pid and then the child >checks if it's parent's parent still exists using 'getpgrp2(pid)' which fails >if the process no longer exists or is not of the same uid. Hmm, except that the machines who can't just catch SIGHUP, those with job control, are mostly Berkeley based systems which don't have getpgrp2 ... Rob -- UUCP: ...!mcvax!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick ARPA: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (03/26/89)
In article <127@titania.warwick.ac.uk> cudcv@warwick.ac.uk (Rob McMahon) writes: >In article <9120@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >>For systems with csh and job control, you could use the new newmail and put >>"/bin/kill -1 -1" in .logout. This probably has bad effects for root and if >>you are logged in more than once. Code for a better solution would be >>welcomed. > >... and if you've got any background jobs you want to survive. This isn't a problem with "kill -1 -1". Remember that csh sets up background jobs to ignore SIGHUP. -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Ann Arbor, MI mailrus!b-tech!zeeff
cudcv@warwick.ac.uk (Rob McMahon) (04/04/89)
In article <9162@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: |In article <127@titania.warwick.ac.uk> cudcv@warwick.ac.uk (Rob McMahon) |writes: |>In article <9120@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon |>Zeeff) writes: |>>For systems with csh and job control, you could use the new newmail and put |>>"/bin/kill -1 -1" in .logout. This probably has bad effects for root and |>>if you are logged in more than once. |> |>... and if you've got any background jobs you want to survive. | |This isn't a problem with "kill -1 -1". Remember that csh sets up background |jobs to ignore SIGHUP. Not on systems with job control it doesn't, it puts new jobs in their own process group so that they never see the normal SIGHUP send on logout, but it doesn't cause them to ignore them. Rob -- UUCP: ...!mcvax!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick ARPA: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England