Take the 2-minute tour ×

I have written a script that I am using to push and deploy a new service to several machines under my control, and in order to execute the process I am using ssh to remotely start the process. Unfortunately, whenever I use SSH to start the process, the SSH command never seems to return, causing the script to stall.

The command is specified as: ssh $user@$host "/root/command &". Whenever I run simple commands, such as ps or who, the SSH command returns immediately, however when I try and start my process it does not return. I have tried tricks like wrapping my process in a simple bash script that starts the process and then exits, however this also hangs the SSH command (even if the bash script echos a success message, and exits normally).

Does anyone have any insight into what is causing this behaviour, and how I can get the SSH command to return as soon as the process has been started?

Thanks for your insights!

share|improve this question
Post the exact command line you are using ... omit passwords/usernames/IPs –  Joseph Kern Jul 6 '09 at 15:26
ssh $SSH_USER@$HOST_ADDR "/root/AppName &" –  rmrobins Jul 6 '09 at 15:30
I should mention that I have set up SSH keys, so it is not necessary to use passwords to run commands on the remote systems. –  rmrobins Jul 6 '09 at 15:32
@rmrobins, a very good step -- setting public key auth. –  nik Jul 6 '09 at 15:34
add comment

5 Answers

up vote 15 down vote accepted

SSH connects stdin, stdout and stderr of the remote shell to your local terminal, so you can interact with the command that's running on the remote side.

As a side effect, it will keep running until these connections have been closed, which happens only when the remote command and all its children (!) have terminated (because the children, which is what "&" starts, inherit std* from their parent process and keep it open).

So you need to use something like

ssh user@host "/script/to/run < /dev/null > /tmp/mylogfile 2>&1 &"

The <, > and 2>&1 redirect stdin/stdout/stderr away from your terminal. The "&" then makes your script go to the background. In production you would of course redirect stdin/err to a suitable logfile.




Just found out that the < /dev/null above is not necessary (but redirecting stdout/err is). No idea why...

share|improve this answer
Thanks, this is exactly what I was looking for - it didn't occur to me that the process would inherit the std* even when using & to launch it in the background. –  rmrobins Jul 6 '09 at 15:52
add comment

Another alternative would be to fire up a detached screen(1), something like:

ssh -l user host "screen -d -m mycommand"

This will start a detached screen (which captures all the interaction inside of it) and then immediately return, terminating the ssh session.

With a bit more ingenuity, you can solve quite complex remote command calls this way.

share|improve this answer
add comment
         This is useful if ssh is going to ask for passwords or
         passphrases, but the user wants it in the background.  This
         remote site is with something like ssh -f host xterm.

         If the ExitOnForwardFailure configuration option is set to “yes”,
         then a client started with -f will wait for all remote port for‐
         wards to be successfully established before placing itself in the
share|improve this answer
The issue with this method is that the SSH command is not actually terminated, it is simply hidden in the background, so the host running the script will have a large number of SSH commands in the background that never return because the SSH commands never return (i.e. the root problem I wish to solve) –  rmrobins Jul 6 '09 at 15:38
add comment

You could try nohup. Man nohup for more details.

ssh host "nohup script &"

If you want to keep the output on the remote machine, here's a variant.

ssh user@host 'export REMOTE=myname; nice nohup ./my-restart >
logfile.log 2>&1 &'
share|improve this answer
add comment

I think the correct way would be

ssh user@host exec script.sh &
share|improve this answer
No, that does not work for me. Why should it? –  sleske Jul 6 '09 at 15:45
I have not used the background push over ssh, was trying without a term at hand. my bad. –  nik Jul 6 '09 at 16:01
add comment

Your Answer


