0

I use the following script to restart a Java server running on a Solaris Sun 5.10 box...

pkill -9 java

nohup ./start_java.sh &

tail -f smx.log

I SSH to the box (using Putty) to run the script.

It works fine as long as I ctrl-c out of the tail -f before closing putty. If I don't stop the tail (just close the putty window), it kills the start_java process.

I have since changed the script to remove the tail -f, but I'm confused as to why this would happen?

3 Answers 3

2

Write a script that does this:

#!/bin/bash    
trap 'echo hup' hup
trap 'echo int' int
trap 'echo quit' quit
trap 'echo abrt' abrt
trap 'echo kill' kill
trap 'echo usr1' usr1
trap 'echo usr2' usr2
trap 'echo term' term
trap 'echo chld' chld
trap 'echo cont' cont
trap 'echo stop' stop
trap 'echo tstp' tstp
trap 'echo ttin' ttin
trap 'echo ttou' ttou

shopt huponexit
sleep 10
echo $(date) process $$ done

Write a second script that does : > nohup.out; nohup firstscript& echo sleeping; sleep 10. Run the second script, wait a second or two, then close your PuTTY terminal. Open a new PuTTY terminal and inspect the nohup.out file. It should tell you what signal the first script received that made it stop. That will help you figure out how to proceed. You could try doing trap '' THEGUILTYSIGNAL for one thing.

It should also tell you the huponexit value. If this is on, you could experiment with shopt -u huponexit and see if that improves matters. (Improvement = you can run the second script then close your PuTTY terminal but the first script still runs to completion.)

0

Nohup should work but in my experience sometimes clients actually sigkill instead of sighup so it ends up killing your processes instead of just telling them to hang up (like nohup prevents). Screen is one possible solution to the problem since it ignores sigkill but it also has its own problems that you'll have to work around.

It may be that having a running process makes your terminal (or Putty) send sigkill.

0

While screen is probably the best way to handle this, one alternative, if you're scripting with bash, would be to disown your start_java.sh process after starting it. This disassociates the process from the terminal, so when you close PuTTY any SIGKILL sent to running processes will not be sent to that process.

Another alternative would be to use tcsh, which automatically disowns backgrounded processes when it exits, instead of SIGKILL'ing them.

I think you can just add disown into your script like this:

#!/bin/bash
# might need to specify bash in the line above for this to work right

pkill -9 java
nohup ./start_java.sh &
disown

tail -f smx.log
4
  • I thought disown was supposed to have the same effect as nohup. I just wrote a script to test this, running nohup foo&; ps -p $! -o pid,ppid,blocked,caught,ignored,pending,pgrp,sess; disown; sleep 1; ps -p $! -o pid,ppid,blocked,caught,ignored,pending,pgrp,sess. And sess doesn't change, so disown doesn't "dissociate the process from the terminal" in that sense. But there is some difference: SIGCHLD becomes blocked, and TTIN and TTOU become caught. I'm not sure those differences would help here.
    – dubiousjim
    Feb 16, 2010 at 12:47
  • @profjim - disown should make the process a child of init, if i understand it right, so you should see PPID change. but i'm honestly not certain; i'd really need to sit down and experiment, which i haven't had time to do. Feb 16, 2010 at 19:42
  • @quack, not with bash 4.1.2. it doesn't seem to. PPID, PGRP, SESS all stay the same. I've been puzzled myself whether there's every any use to disowning something you nohup'd in the first place. (Interactively, disown is useful if you didn't already use nohup on the original invocation.)
    – dubiousjim
    Feb 16, 2010 at 19:59
  • @profjim - you may be right, i may be misremembering that situation (disown when you didn't use nohup). Feb 16, 2010 at 20:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .