[ILUG] i killed the head but the body keeps moving

[Hunt, Bryan]

cheers Padraig .... it's turning out to be fairly arkward to shut this thing
down 
those java threads just dont respect the HUP... on another topic that watch
command is
a handy one ... before now what I've been doing for a lot of commands has
been like ....

while [ 1 ] ; do cat /proc/sys/fs/file-nr; sleep 1 ; clear;  done

not the most efficient 

--B


-----Original Message-----
From: Padraig Brady [mailto:padraig at antefacto.com]
Sent: Wednesday, May 22, 2002 12:29 PM
To: Hunt, Bryan
Cc: Ilug (E-mail)
Subject: Re: [ILUG] i killed the head but the body keeps moving


I think the shell will only kill it's children
on a signal when it's interactive, and in summary
I don't know how to get around this.

As a side note, I find the following very useful for seeing the
process tree hierarchy of the system: watch -n1 pstree -p

If you're using bash, it at least does the following:

When bash is a login shell it will NOT kill children on SIGHUP.
When bash is a non interactive shell it will NOT kill children on exit.
When bash is interactive, it ignores SIGTERM.
In all cases, bash ignores SIGQUIT.
If job control is in effect, bash ignores SIGTTIN, SIGTTOU, and SIGTSTP.
signals of jobs started by bash are set to the same as bash's parent.
Background jobs (jobs started with &) ignore SIGINT and SIGQUIT.
and to be complete, commands run as a result of command substitution 
ignore the keyboard-generated job control signals SIGTTIN, SIGTTOU, and 
SIGTSTP.

I only skimmed the following but it seemed useful/related:
http://www.cons.org/cracauer/sigint.html

Padraig.

Hunt, Bryan wrote:
> Quick question .....
> 
> A script calls a java program (a web server) ie 
> ./build.sh jetty-smart &
> processnum=$! 
> 
> Then i sleep ...
> sleep 60 
> 
> Then I run another task ....
> ./build.sh unittests
> 
> Then I want to kill the web server ...
> kill ${processnum} 
> 
> The problem is that this kills the head but the webserver and all its
> processes continue on in zombie mode .... 
> 
> Is there a specific signal that I should be using here or is it going to
be
> a problem regardless cause of dodgy pthread related problems ?
> 
> Ta 
> --B