Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 10 Feb 2012 21:20:12 GMT
From:      Diomidis Spinellis <dds@aueb.gr>
To:        freebsd-bugs@FreeBSD.org
Subject:   Re: bin/164947: tee looses data when writing to non-blocking file descriptors
Message-ID:  <201202102120.q1ALKCGp091543@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/164947; it has been noted by GNATS.

From: Diomidis Spinellis <dds@aueb.gr>
To: Martin Cracauer <cracauer@cons.org>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/164947: tee looses data when writing to non-blocking file
 descriptors
Date: Fri, 10 Feb 2012 23:17:03 +0200

 On 10/02/2012 23:03, Martin Cracauer wrote:
 > Diomidis Spinellis wrote on Fri, Feb 10, 2012 at 10:32:02PM +0200:
 >> On 10/02/2012 21:17, Martin Cracauer wrote:
 >>> Diomidis Spinellis wrote on Fri, Feb 10, 2012 at 07:04:41AM +0000:
 >>>>
 >>>>> Number:         164947
 >> [...]
 >>
 >>>>> How-To-Repeat:
 >>>> Run the following:
 >>>> #!/usr/local/bin/bash
 >>>> # bash needed for the>(...) functionality
 >>>> # ssh apparently sets O_NONBLOCK
 >>>> # Remove the 2>/dev/null to see tee complaining
 >>>> dd count=100000 if=/dev/zero |
 >>>> tee>(ssh localhost dd of=/dev/null) 2>/dev/null |
 >>>> (ssh localhost dd of=/dev/null)
 >>>
 >>> I don't think it is ssh that is causing this. If you use a named pipe
 >>> explicitly and hook ssh up to that the error doesn't appear.  Seems to
 >>> be something that bash is doing there.
 >>
 >> I think the named pipe isolates the write fd from the ssh end.  If you
 >> use cat or dd instead of ssh the problem goes away.
 >
 > Do you happen to know what bash does there, exactly? I was assuming it
 > is creating a named pipe behind the user's back.
 
 It is creating a normal pipe and providing it as an argument through 
 /dev/fd.  Try
 
 ls -l /dev/fd >(wc -l)
 
 > I noticed that if you do ssh on the "tee part" and something else on
 > the end of the regular pipe then things also fail.  On the other hand
 > if you put the "tee part" on something else and the regular pipe on
 > ssh things never seem to fail.
 
 On 8.1 release I needed both ends to run ssh to see the problem.
 
 
 BTW The problem also manifests itself on Mac OS X and Linux :-)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201202102120.q1ALKCGp091543>