Background processes not dying on parent exit
Kevin W. Hammond
OS....
I ran a process in the background from tcsh with the ampersand (&). I would
have expected that when I logged out of the shell that my background processes
would have died as well, but they didn't.
Is the shell responsible for killing the background processes, or, since the
shell is the parent of them and has been terminated, shouldn't the OS kill
the processes automatically?
I'm using tcsh 6.01 and linux 0.97pl2.
-kwh-
--
Kevin W. Hammond
ham...@kwhpc.caseng.com
CASE Engineering * 575 W. Madison #1601 * Chicago, IL 60661 * (312)902-2161
David Barr
>I'm not sure if this is a shell problem or OS problem.
Neither; the behavior you are about to describe is normal.
> I'll start with the
>OS....
>I ran a process in the background from tcsh with the ampersand (&).
>I would have expected that when I logged out of the shell that my
>background processes would have died as well, but they didn't.
>Is the shell responsible for killing the background processes, or,
>since the shell is the parent of them and has been terminated,
>shouldn't the OS kill the processes automatically?
The processes are not supposed to go away unless they are suspended
for some reason. Another thing to watch out for: if someone logs in
on the tty you were on when you started the jobs, they will get the
output from your program.
Drew Eckhardt
>I'm not sure if this is a shell problem or OS problem. I'll start with the
>OS....
>
>I ran a process in the background from tcsh with the ampersand (&). I would
>have expected that when I logged out of the shell that my background processes
>would have died as well, but they didn't.
This is perfectly normal.
>Is the shell responsible for killing the background processes, or, since the
No.
>shell is the parent of them and has been terminated, shouldn't the OS kill
>the processes automatically?
No.
Under csh shells, the default behavior is to set the HUP signal handler
to "ignore" for any processes started with &. Ie, there is an implied
nohup. So, when you logout, sending a HUP signal to all your children,
they're allowed to ignore it.
Bourne shells have a different behavior.
>I'm using tcsh 6.01 and linux 0.97pl2.
>
>-kwh-
>--
>Kevin W. Hammond
>ham...@kwhpc.caseng.com
>
> CASE Engineering * 575 W. Madison #1601 * Chicago, IL 60661 * (312)902-2161
--
Microsoft is responsible for propogating the evils it calls DOS and Windows,
IBM for AIX (appropriately called Aches by those having to administer it), but
marketing's sins don't come close to those of legal departments.
Boycott AT&T for their absurd anti-BSDI lawsuit.
Kevin W. Hammond
| In article <1992Aug31.0...@athena.mit.edu> you write:
| |>
| |> I ran a process in the background from tcsh with the ampersand (&). I would
| |> have expected that when I logged out of the shell that my background processes
| |> would have died as well, but they didn't.
| |>
| |> the processes automatically?
| |>
|
| logout, allowing another person to use the computer while your job is running.
|
I thought that was supposed to happen only if you ran the background job via
nohup. In otherwords, when then parent shell would exit, it would send SIGHUP
to all of it's children, letting them know the parent was exiting. Running
the program nohup would make the child immune to such a signal.
Ross Biro
>
>The processes are not supposed to go away unless they are suspended
>for some reason. Another thing to watch out for: if someone logs in
>on the tty you were on when you started the jobs, they will get the
>output from your program.
Since init now uses vhangup this won't be a problem. Linux
vhangup should even catch references to the controlling terminal via
/dev/tty.
Ross Biro bi...@leland.stanford.edu
Member League for Programming Freedom (LPF)
mail lea...@prep.ai.mit.edu for information
Bryan Curnutt
>|
>| |>
>| |> I ran a process in the background from tcsh with the ampersand (&). I would
>| |> have expected that when I logged out of the shell that my background processes
>| |> would have died as well, but they didn't.
>|
>
>nohup.
True. But both csh and tcsh automatically nohup all background jobs.
--
Any opinions above are mine, and do not necessarily reflect the views of SAI.
Bryan Curnutt | "I hope that UNIX is more like my diner
bryan%uhu...@uunet.uu.net | than like McDonald's." -- Doug McIlroy
Paul Zimmerman
Umm, I'm pretty sure your background processes are supposed to get a
SIGHUP when you log out, unless they are started with nohup or they ignore
the SIGHUP signal. At least it works that way on my SVR3 system here at
work. Is this different under POSIX? BSD?
Curious,
Paul
--
Paul Zimmerman -- pa...@colosus.Convergent.COM
"I toast, therefore I am." - AI toaster from _Red Dwarf_
Brett G Person
>ham...@kwhpc.caseng.com writes:
>>Is the shell responsible for killing the background processes, or, since the
>>shell is the parent of them and has been terminated, shouldn't the OS kill
>>the processes automatically?
>
Why is it done this way? This is kinda sloppy. I know that
somethimes unix will forget to kill one of my processes, but it
doesn't seem to happen very often. Why would linux be designed this
way?
I think that all processes that aren't specifically nohup'ed should
have to die when their parents die.
--
Brett Person
Guest Account
North Dakota State University
per...@plains.nodak.edu || per...@plains.bitnet
"Freedom's just another word for nothin' left to loose"
Kari E. Hurtta
understand without repeating.>
In article <20...@plains.NoDak.edu> per...@plains.NoDak.edu (Brett G Person ) wrote:
> Why is it done this way? This is kinda sloppy. I know that
> somethimes unix will forget to kill one of my processes, but it
> doesn't seem to happen very often. Why would linux be designed this
> way?
>
> I think that all processes that aren't specifically nohup'ed should
> have to die when their parents die.
Linux does what programs ask to it do.
It is shell, what is designed this way. From csh's manual page:
"All processes detached with & are effectively nohup'd." This
apply also to tcsh.
So ask from writer of csh.
- K E H
( Kari....@Helsinki.FI,
hur...@cc.Helsinki.FI,
hur...@cs.Helsinki.FI,
HUR...@FINUH.BITNET
)
Rob Levin
a
PZ> SIGHUP when you log out, unless they are started with nohup or they
ignore
PZ> the SIGHUP signal. At least it works that way on my SVR3 system
here at
PZ> work. Is this different under POSIX? BSD?
SIGHUP is not a POSIX.1-defined signal. The other POSIX standards are
presently draft standards, but perhaps someone else can shed some
light....
Rob L.
* Origin: Via the Annex in Victoria, TX (1:3802/217)
Joost Helberg
at Oracle Corporation. The opinions expressed are those
of the user and not necessarily those of Oracle.
ham...@kwhpc.caseng.com (Kevin W. Hammond) writes:
: I'm not sure if this is a shell problem or OS problem. I'll start with the
: OS....
:
: I ran a process in the background from tcsh with the ampersand (&). I would
: have expected that when I logged out of the shell that my background processes
: would have died as well, but they didn't.
All processes in the same pgrp with the controlling tty you switch off get
a SIGHUP. This means that backrground processes get killed unless:
they ignore SIGHUP
the tty is not their controlling tty anymore
:
: Is the shell responsible for killing the background processes, or, since the
: shell is the parent of them and has been terminated, shouldn't the OS kill
: the processes automatically?
The tty-driver is responsible for doing this as it kwnos about controlling
tty's.
This scheme works for all tty-driver signals: SIGQUIT, SIGINT and SIGHUP.
Just write a program which catches SIGINT, start it in background and type
DEL (or ctr-C). It will get this signal.
The shell is aware of all this and ignores these signals for a process
started in background.
As far as I know, the SIGHUP however should not be ignored!
--
Joost Helberg Rijnzathe 6
jhel...@oracle.nl NL-3454 PV De Meern
jhel...@nl.oracle.com The Netherlands
Oracle Europe BV Product Line Development
Phone: +31 3406 94211 Fax: +31 3406 65609
Keith Smith
>I said that children shouldn't be killed when their parent dies.
That depends, see below...
>
>per...@plains.NoDak.edu (Brett G Person ) asks in reply:
>>Why is it done this way? This is kinda sloppy. I know that
>>somethimes unix will forget to kill one of my processes, but it
>>doesn't seem to happen very often. Why would linux be designed this
>>way?
>
>As far as I am aware, no Unix kills children when the parent dies. I
>see no reason why processes should be killed for arbitrary reasons like
>some other process dying.
That depends on the shell you are using and NATURE of the process. It
should be up to the forked process whether or not it dies, not the OS.
The DEFAULT action needs to be death!
What SHOULD happen in my experience is the CHILD process should receive
a SIGHUP when the parent dies. The DEFAULT action for SIGHUP should be
death. This is VERY important from a minimal security standpoint.
The child process can dissassociate itself from it's parent with the
setpgrp() System call. Alternately it can also choose to trap the
SIGHUP signal and continue on accordingly.
In SCO ISC and SVR4 a standard forked shell job dies when you log out
unless it is 'nohup'ed:
someprog < /dev/null >$HOME/someprog.out 2>&1 &
someprog:
-------
: # For SCO
#!/bin/sh for other stuff
while true
do
date
sleep 600 # 10 Minutes
done
-------
>
>Also, do you think that the following should work:
>
> #!/bin/sh
> (sleep 10; echo 10) &
> (sleep 5; echo 5) &
>
>A similar thing happens with some program, e.g. some mailers leave a
>background child process behind to do the real work, so that the user
>doesn't need to wait as long for a prompt. Should this be impossible?
No, The script would need to 'nohup' the background children, *OR* the
script itself could be nohup'ed, *OR* the program if written in 'C' can
setpgrp or trap SIGHUP. Most mailer type jobs will fork and spool the
work, otherwise the set the signal or process group to protect
themselves.
>
>Note that doing nohup isn't the answer: it could still be a good idea
>for some leftover child processes of this kind to be killed on hangup.
>
Now, also note that certian shells (tcsh for 1 and I THINK ksh will
warn you at logout, but I'm not sure on this one) Automagically nohup
all the shells doing a signal(SIGHUP,SIG_IGN) before forking it off.
--
Keith Smith uunet!ksmith!keith 5719 Archer Rd.
Digital Designs BBS 1-919-423-4216 Hope Mills, NC 28348-2201
Somewhere in the Styx of North Carolina ...