kill xterm kills app!

[Tom 'Needs A Hat' Mitchell]

On Wed, Apr 28, 2004 at 10:24:35PM -0500, Paul D. Brown wrote:
> On Wed, 2004-04-28 at 10:18, Jay Daniels wrote:
> > If I open a terminal and run a program in the background using the "&"
> > when I close the terminal the program gets killed.
> > 
> > xclock &
> > x out of terminal kills xclock!
> > 
> > How do I prevent this?

To understand this you have to know what is killing it.  ;-)

When you kill the xterm or gnome-terminal all the processes with it
are sent a hangup signal, (HUP or TERM).  You can strace it to see the exact
signal if you are unsure. See the man pages for kill and signal and
look for HUP.

     man -a signal

If you do "xclock &" you do nothing special to manage the HUP signal.
You are only invoking jobcontrol of the shell if it supports it (see signal, 
SIGCONT) to manage the process.

If you have an xterm running bash and do "xclock &" the shell
continues to manage the process as a 'job'. If you kill the terminal
xclock vanishes. Of interest if you type:

   ( /bin/sh -c "xclock -update 2" & ) 

the clock will not be sent the HUP signal because /bin/sh in the
subshell does not do job control and 'sh' is the parent.

The environment variable SHELL can be critical:
   $ export SHELL=/bin/sh
   $ (xclock -update  2 &)
Now the subshell invoked by the "( )" pair does not do job control
and when the window is killed there is not controlling terminal
to deliver the HUP signal.  So depending on $SHELL things can act 
differently adding to the confusion.

> If you start it with the ampersand and later want to close the xterm but
> keep the other app (xclock) going, you can use 'disown' to do the same
> thing that 'nohup' does when starting it as mentioned in earlier posts. 
> For example:
> 
> $ xclock &
> $ disown xclock

"disown" is cool...

    $ xclock &
    [1] 12393
    $ jobs
    [1]+  Running                 xclock &
    $ disown xclock
    $ jobs
    $

It is important to know that "disown" is a builtin command of bash.
Users of other shells need to look for other ways to get the same
action.   

Since  "disown" is a built in for bash it is useful to know about "nohup"
(/usr/bin/nohup).  xclock does nothing interesting with input and output
but other processes do so think about  file redirection and other IO issues
with nohup (see the file nohup.out).  Play with job control here.

 nohup xclock &
 nohup xclock
 ^z	# control Z if you forgot the &
 bg	# tell it to run in the background
 jobs
 fg %1

Ksh users need to know that 'nohup' is an alias in ksh and that the
"hupedness" is expected to change to be compatible with the original
ksh. ;-)  did I invent a word.


It is interesting in a "ps -elf| grep xclock" listing look at the tty column.
   # xclock $
   # ps -elf| grep xclock
   # disown xclock
   # ps -elf| grep xclock

You can see it be disconnected from a controlling terminal.

Someone mentioned "screen".  This is interesting because it persists
over login sessions and more.  This is worth its own thread.

Above I said, "To understand this you have to know what is killing it."
I cannot leave the smiling face hanging without a start at an answer.
In one terminal window  start 
   xclock &
In another terminal find the process id number
   ps -efl | grep xclock
If the process number is 1234, trace xclock with strace.  
   strace -p 1234
Once strace is attached kill the terminal window and you 
will see a lot of junk that ends with:
  gettimeofday({1083316597, 28387}, NULL) = 0
  select(5, [3 4], [], [], {39, 971291})  = ? ERESTARTNOHAND (To be restarted)
  --- SIGHUP (Hangup) @ 0 (0) ---
  Process 12620 detached
So now we know that it died after being sent SIGHUP (hangup).  And "apropos
hangup" would find an interesting man page.  ;-)

Yes, This is hard stuff.


-- 
	T o m  M i t c h e l l 
	/dev/null the ultimate in secure storage.