Re: [PATCH] tee: recover from EAGAIN returned from fwrite()

[Kamil Dudka]

On Friday, September 7, 2018 5:21:04 AM CEST Pádraig Brady wrote:
> On 06/09/18 07:28, Kamil Dudka wrote:
> > tee expects the output descriptors to operate in blocking mode but this
> > assumption might be invalidated by other programs connected to the same
> > terminal, as in the following example:
> > 
> > $ telnet ... | tee log_file
> > 
> > telnet calls ioctl(stdin, FIONBIO, [1]), which causes the O_NONBLOCK
> > flag to be set on tee's output, which is connected to the same terminal.
> > 
> > This patch has zero impact unless EAGAIN returns from fwrite().  In that
> > case we try to reset the O_NONBLOCK flag on the output file descriptor
> > and retry the call to fwrite().
> 
> Not sure about this.

I was actually surprised that I did not find similar reports in the archive.

> Would that not be changing the tty to blocking, which is not what telnet
> wants?

It probably does not matter in this specific case.  At least I was not able
to observe any negative impact on the user session.  Everything seemed to
work as if the output was not redirected.

As it is now, the user ends up with unexpectedly frozen output while input 
still consumes anything that the desperate user types while trying to escape 
the supposedly frozen telnet session.

> Also this would be a general issue. Why treat tee specially here?

Yes, this may happen with any filter-like utility that does not handle
EAGAIN while writing its output.  Still I believe that recording a session
using 'tee' is the most common use case and we have a very specific report 
about it in Red Hat Bugzilla.

> Also would `cat | telnet ... | tee blah` be a workaround?

The above command does not really work because telnet is unable to set all the 
other needed properties on the terminal.  So it let me write my password on 
the screen (because 'echo' was not disabled), arrow keys in my shell session 
did not work, etc.

Kamil

> thanks for the patch,
> Pádraig