Re: fd used for saving redirected fds leaked to child processes

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sun, Aug 13, 2017 at 9:12 AM, Stephane Chazelas
<stephane.chazelas@xxxxxxxxx> wrote:
> In:
>
> mkfifo fifo
> zsh -c '{ echo GO > fifo & echo $!; } > pid; echo done' | cat
>
> "cat" hangs until some process  open the fifo in read mode, even
> though that "echo GO > fifo" command was run in background and
> "done" is output straight away.

Hmm.  Here in a bit more detail is what I believe is going on:

There is a parent shell (probably also zsh in this example) managing
the two processes "zsh -c ..." and "cat".  Following zsh's usual
practice, the "zsh -c" process has been forked (in case "cat" is a
builtin) and then "cat" has also been forked (because it's not a
builtin).  Thus the stdin of "cat" is connected to the stdout of "zsh
-c" as you would expect.

Looking inside that "zsh -c", the "{ ... }" construct is supposed to
be executed in the current shell.  So *that* zsh saves its stdout as
fd 12, redirects the "{ ... }" output to the "pid" file, and begins
handling what's inside the braces.  At this point fd 12 cannot be
closed, because the current shell still needs it in order to restore
stdout.

Now zsh does "echo GO > file &".  It is after zsh forks to background
this process that fd 12 might become irrelevant.  However, (the subtle
bit), zsh attempts to process all the redirections first, before doing
the cleanup of the file descriptors that the child process doesn't
need.  So it blocks on opening the fifo with fd 12 still open, even
though it would eventually close fd 12 before "echo" is executed.

You can demonstrate this because even using /bin/echo in the example
above, which would invoke the close-on-exec flag, still blocks in
exactly the same way.

The question is how it's possible to address this without
"accidentally" closing descriptors that might legitimately be managed
with further redirections e.g. X>&Y.