ssh client is setting O_NONBLOCK on a pipe shared with other processes

[Doug Graham]

> ssh has to set NONBLOCK otherwise it can, well, block - there's
> no way for ssh to know a priori how much data it can write to a fd.

I don't know anything about how ssh is structured, but I think it must
be a bit more complicated than that. Ssh only sets O_NONBLOCK on an
fd if isatty(fd) returns false, so it's able to function with blocking input
and output if the relevant descriptor refers to a tty (probably the usual
case).


On Sun, Sep 15, 2019 at 10:20 PM Damien Miller <djm at mindrot.org> wrote:
>
> On Sun, 15 Sep 2019, Doug Graham wrote:
>
> > The quick summary is that we invoke git from a parallel invocation of
> > "make".  Git invokes ssh to pull stuff from a remote repo. Ssh sets
> > O_NONBLOCK on stdout and stderr if they do not refer to a tty. During
> > our build, stderr refers to a pipe that other jobs run by make (and
> > make itself) may also write to, and since this is a parallel build,
> > they may write to that pipe while ssh has it in non-blocking mode.
> >
> > Make occasionally gets an unexpected EAGAIN error and fails the build
> > with the error message "make: write error".
> >
> > We have a workaround, but it seems to me that this could cause
> > problems with other background uses of ssh too.  Should ssh really be
> > setting O_NONBLOCK if it is running non-interactively?
>
> ssh has to set NONBLOCK otherwise it can, well, block - there's
> no way for ssh to know a priori how much data it can write to a fd.
>
> -d