> 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@xxxxxxxxxxx> 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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
