Re: bash -c 'sleep 5 &' vs. ssh user@host 'sleep 5 &'

[Clark Wang]

On Tue, Sep 22, 2020 at 2:01 PM Robert Elz <kre@munnari.oz.au> wrote:

>     Date:        Tue, 22 Sep 2020 10:02:07 +0800
>     From:        Clark Wang <dearvoid@gmail.com>
>     Message-ID:  <
> CADv8-ogF0HEv-ckEgXY9DQ1yPcZ4BDpkjY_7AeX83O1Db93PLA@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