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?

  • Post the exact command line you are using ... omit passwords/usernames/IPs Jul 6, 2009 at 15:26
  • ssh $SSH_USER@$HOST_ADDR "/root/AppName &"
    – rmrobins
    Jul 6, 2009 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, 2009 at 15:32
  • @rmrobins, a very good step -- setting public key auth.
    – nik
    Jul 6, 2009 at 15:34

5 Answers 5


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...

  • 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, 2009 at 15:52
  • +1! Works for me. And you can also print the output by echo the log file: ssh user@host "/script/to/run > /tmp/ssh.stdout 2>&1 && cat /tmp/ssh.stdout && rm -f /tmp/ssh.stdout" Feb 18, 2016 at 9:57

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 &'

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.

 -f      Requests ssh to go to background just before command execution.
         This is useful if ssh is going to ask for passwords or
         passphrases, but the user wants it in the background.  This
         implies -n.  The recommended way to start X11 programs at a
         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
  • 1
    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, 2009 at 15:38

I think the correct way would be

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.