O problema aqui é que sshd
aguarda o fim do arquivo no canal que está lendo o stdout do comando (não o stderr por algum motivo, pelo menos com a versão que estou testando). E o trabalho em segundo plano herda um fd nesse pipe.
Então, para contornar isso, redirecione a saída do comando background rsync
para algum arquivo ou /dev/null
se você não se importar com isso. Você também deve redirecionar o stderr, porque mesmo que o sshd não esteja esperando pelo canal correspondente, após sshd
sair, o canal será quebrado, então rsync
será eliminado se ele tentar escrever no stderr.
Então:
rsync ... > /dev/null 2>&1 &
Compare:
$ time ssh localhost 'sleep 2 &'
ssh localhost 'sleep 2 &' 0.05s user 0.00s system 2% cpu 2.365 total
$ time ssh localhost 'sleep 2 > /dev/null &'
ssh localhost 'sleep 2 > /dev/null &' 0.04s user 0.00s system 12% cpu 0.349 total
E:
$ ssh localhost '(sleep 1; ls /x; echo "$?" > out) > /dev/null &'; sleep 2; cat out
141 # ls by killed with SIGPIPE upon writing the error message
$ ssh localhost '(sleep 1; ls /x; echo "$?" > out) > /dev/null 2>&1 &'; sleep 2; cat out
2 # ls exited normally after writing the error on /dev/null instead
# of a broken pipe