On Tue, Sep 22, 2020 at 2:01 PM Robert Elz <k...@munnari.oz.au> wrote:
> Date: Tue, 22 Sep 2020 10:02:07 +0800 > From: Clark Wang <dearv...@gmail.com> > Message-ID: < > cadv8-ogf0hev-ckegxy9dq1ypcz4bdpkjy_7aex83o1db93...@mail.gmail.com> > > | In an interactive shell (in case this matters), run bash -c 'sleep 5 > &' and > | it exits immediately without waiting for the sleep to complete. But ssh > | user@host 'sleep 5 &' (with bash as the login shell) would wait for > sleep > | to complete. Why the difference? > > It isn't bash waiting for the sleep to complete, it is ssh waiting for > the connection to close. Neither ssh nor the sshd at the target know that > "sleep" doesn't write any output, so they have to keep the connection alive > (and hencs ssh running on the client end) until the command has completed > (actually, until it closes its fds, so you could do > > ssh user@host 'sleep 5 >&- 2>&- &' > > if you wanted (no need to worry about stdin, because it is an async > process, that gets connected to /dev/null anyway). This shows > stdout & stderr being closed - that part is not important (just the > briefest sane example to give) - you could also redirect them to > anywhere else (just remember that it has to be both of them). > Ah right. I misunderstood something else. When I run $ ssh 127.0.0.1 '{ sleep 120 | cat; } & exit' and on another tty I did this $ pgrep -af sleep 83207 ssh 127.0.0.1 { sleep 120 | cat; } & exit 83215 bash -c { sleep 120 | cat; } & exit 83216 sleep 120 I wrongly thought the process 'bash -c ...' in pgrep's output is the parent bash but it should be the forked child bash. Then, how should we explain that $ ssh -t 127.0.0.1 'sleep 120 &' would complete immediately? -clark