Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

i want to run a shell script remotely via ssh and the ssh shell should end when the script ends. The script itself runs another script whose output is piped to a log file.

Example: I run the script

function logpipe() {
    while read line;do
        echo $line >> $1

./bin/ $JBOSS_HOSTNAME | logpipe $JBOSS_DIST/log/server.log 2>&1 &

exec "$JAVA" -DJBOSS_PID=_$$_ $JAVA_OPTS \
         -Djava.endorsed.dirs="$JBOSS_ENDORSED_DIRS" \
         -classpath "$JBOSS_CLASSPATH" \
         org.jboss.Main "$@"

Now the problem is when i run

ssh myhost "bin/"

the shell gets "stuck" to the script and i only can get it loose by closing it via Crtl+C. I guess the trick is something between nohup and another piping trick but i just couldn't get to it by now.

share|improve this question
Maybe i asked in the wrong direction. The reason i put the logpipe function to which leaves me with this unending shell is, that the log will be rotated nightly by jboss, where the file is simply renamed. When i log directly like Guss said, the process will still log into the renamed file and not the new one and the log entries aren't chronological anymore. That's why i use this function. Without the function the script leaves the shell as wished, but has the log entries in the wrong file after one day. But i still want to log, what is going to stdout by the process runned in – Sebastian Oct 5 '09 at 14:36

You should try to run your script in a "screen".

screen -D -m

and then you can catch up the screen with:

screen -r

share|improve this answer
There are two types of users: those that use screen, and those that ought to be. – Zimmy-DUB-Zongy-Zong-DUBBY Oct 5 '09 at 15:13

The problem is that the script actually ends, but if it leaves another program connected to the terminal (by backgrounding it), then SSH will still keep the connection attached.

using nohup simply lets the shell know that if an external entity is sending hangup signals, they should be ignored, but it does not actually disconnects the program from the console.

I do not know anyway to explicitly disconnect a program from the terminal, but one thing you can do is send a HUP signal to the SSH session that ran the script using the command

kill -HUP $PPID

this will terminate the SSH connection and will leave the program running, but the calling ssh client will get an ugly "connection closed by remote host" error message.

share|improve this answer
That suggests that the way to do this is to ssh without a tty; can't remember the option for that. – pjc50 Oct 5 '09 at 14:55
SSH normally runs remote commands without a TTY (unless you force it with -t). -T disables this even when running an interactive shell. So tty or no tty - a running program that is attached to the console prevents graceful shutdown of SSH. – Guss Oct 5 '09 at 15:10

ssh myhost "nohup bin/"

Should do the trick.

share|improve this answer
It doesn't. It still leaves my hanging in the shell, from where i can only escape through Ctrl+C. – Sebastian Oct 5 '09 at 14:03

I believe you're correct about nohup. In, try changing the last line to:

nohup ./bin/ $JBOSS_HOSTNAME | logpipe $JBOSS_DIST/log/server.log 2>&1 &
share|improve this answer

In addition to ssh -t mentioned above, which I think will work, you should be sure to close all of your script's inputs & outputs:

ssh myhost "bin/ > yourlog 2>&1 < /dev/null"

All credit to the OpenSSH FAQ, where I found this years ago.

share|improve this answer
You can use -n instead of < /dev/null. – Teddy Nov 18 '09 at 17:37

What happens if sources

. ./bin/ $JBOSS_HOSTNAME | logpipe $JBOSS_DIST/log/server.log 2>&1 &
share|improve this answer

It's most probably file descriptors fd>2 that are still open. Check with lsof.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.