similar to: [Bug 26] ssh setting O_NONBLOCK on stderr can upset CVS

http://bugzilla.mindrot.org/show_bug.cgi?id=26 ------- Additional Comments From markus at openbsd.org 2002-08-23 08:21 ------- hm, what do you suggest? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

> 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

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

> Case in point; EAGAIN can come if you give your fd to another process > and continue using it yourself. > Short counts; It is documented behavior that read() and write() may > return short counts. It is not documented why, so you can not make > any assumptions. You might be right about short counts but if you're right about EAGAIN, there are bugs everywhere. My first

https://bugzilla.mindrot.org/show_bug.cgi?id=1478 Summary: ssh -V sends output to stderr instead of stdout Classification: Unclassified Product: Portable OpenSSH Version: 5.0p1 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Documentation AssignedTo:

On Wed, Jul 15, 2020 at 03:32:55PM +0200, mwilck at suse.com wrote: > From: Martin Wilck <mwilck at suse.com> > > If a program opens /dev/hwrng with O_NONBLOCK and uses poll() and > non-blocking read() to retrieve random data, it ends up in a tight > loop with poll() always returning POLLIN and read() returning EAGAIN. > This repeats forever until some process makes a

On 11/08/2020 12:37, Philippe Mathieu-Daud? wrote: > You Cc'ed qemu-devel, so Cc'ing the virtio-rng maintainers. > > On 7/15/20 3:32 PM, mwilck at suse.com wrote: >> From: Martin Wilck <mwilck at suse.com> >> >> If a program opens /dev/hwrng with O_NONBLOCK and uses poll() and >> non-blocking read() to retrieve random data, it ends up in a tight

On 28/08/2020 23:34, Martin Wilck wrote: > On Wed, 2020-08-26 at 08:26 -0400, Michael S. Tsirkin wrote: >> On Tue, Aug 11, 2020 at 04:42:32PM +0200, Laurent Vivier wrote: >>> On 11/08/2020 16:28, mwilck at suse.com wrote: >>>> From: Martin Wilck <mwilck at suse.com> >>>> >>>> If a program opens /dev/hwrng with O_NONBLOCK and uses poll()

> So the make process gets an EAGAIN on the write syscall and doesn't > retry? That sounds like a bug in whatever make you're using, since > that could potentially occur in other circumstances too. What other circumstances? EAGAIN means that something put the device into non-blocking mode, and normally, that should only happen if the program calling write had itself previously

Hi I'm trying to wrap ssh in an application using glib. For now, I'm launching the ssh client in master mode and want it to detach, keeping the control socket around. I figured I could do that using the -f flag and the usual Control* options to force ssh to daemonize (ideally without executing any command), but it turns out that glib doesn't recognize the daemonized process as

https://bugzilla.mindrot.org/show_bug.cgi?id=2476 Bug ID: 2476 Summary: ssh fails to report IO errors on stdin/stdout/stderr Product: Portable OpenSSH Version: 6.0p1 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P5 Component: ssh Assignee: unassigned-bugs at

https://bugzilla.mindrot.org/show_bug.cgi?id=1988 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #2299|0 |1 is obsolete| | Status|REOPENED |ASSIGNED

https://bugzilla.mindrot.org/show_bug.cgi?id=1988 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|2076 |2543 Status|ASSIGNED |RESOLVED Resolution|--- |FIXED

On 11/08/2020 16:28, mwilck at suse.com wrote: > From: Martin Wilck <mwilck at suse.com> > > If a program opens /dev/hwrng with O_NONBLOCK and uses poll() and > non-blocking read() to retrieve random data, it ends up in a tight > loop with poll() always returning POLLIN and read() returning EAGAIN. > This repeats forever until some process makes a blocking read() call.

On 11/08/2020 16:28, mwilck at suse.com wrote: > From: Martin Wilck <mwilck at suse.com> > > If a program opens /dev/hwrng with O_NONBLOCK and uses poll() and > non-blocking read() to retrieve random data, it ends up in a tight > loop with poll() always returning POLLIN and read() returning EAGAIN. > This repeats forever until some process makes a blocking read() call.

http://bugzilla.mindrot.org/show_bug.cgi?id=785 Summary: ssh client socket may have O_NONBLOCK flag set Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: minor Priority: P2 Component: ssh AssignedTo: openssh-bugs at mindrot.org ReportedBy:

Hello everyone, recently I've found something I consider a bug. Correct me if I'm wrong, but I always thought that Linux' EOL is 0x0A. Imagine my surprise when I saw that all messages that are being output on to the stderr (on any Linux I've tested - Fedora and Ubuntu) are terminated with 0x0D, 0x0A. Maybe that's standard behaviour of all stderr messages in all Linux

https://bugzilla.mindrot.org/show_bug.cgi?id=1988 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #2810|0 |1 is obsolete| | Attachment #2810|ok?(dtucker at zip.com.au) |

Hi, Using OpenSSH 2.9p2 (2.5.2 was also bad), I've noticed data loss on Linux when: 1) ssh -n flag is used, and 2) ssh jobs are run from cron (effectively causing the same as above). What is done, is a command basically like: ssh [-n] -c blowfish -p 722 -i rsakey -l pwget passwdserver passwd > passwd.tmp 2> /tmp/log ie, retrieve dynamically created passwd-file from passwdserver

https://bugzilla.mindrot.org/show_bug.cgi?id=1469 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|NEW |RESOLVED CC|