dial-stdio: handle connections which lack CloseRead method.

[ijc]

This happens on Windows when dialing a named pipe (a path which is used by CLI
plugins), in that case some debugging shows:

DEBU[0000] conn is a *winio.win32MessageBytePipe
DEBU[0000] conn is a halfReadCloser: false
DEBU[0000] conn is a halfWriteCloser: true
the raw stream connection does not implement halfCloser 

In such cases we can simply wrap with a nop function since closing for read
isn't too critical.

Signed-off-by: Ian Campbell ijc@docker.com

My testing on Windows s is limited to

>docker-windows-amd64.exe -D system dial-stdio HTTP/1.1 400 Bad Request Content-Type: text/plain; charset=utf-8 Connection: close 400 Bad Request 

Which failed previously.

This is a replacement/alternative for #1710.

[codecov-io]

Codecov Report

❗ No coverage uploaded for pull request base (master@bf4a96e). Click here to learn what that means.
The diff coverage is 0%.

@@ Coverage Diff @@## master #1718 +/- ##
=========================================
Coverage ? 56.13% =========================================
Files ? 306 Lines ? 21035 Branches ? 0 =========================================
Hits ? 11807 Misses ? 8373 Partials ? 855

[thaJeztah]

ping @AkihiroSuda@tonistiigi PTAL

[AkihiroSuda]

looks good

[ijc]

Is this (or #1710) ready to be merged? I don't think the change is unit testable hence the coverage result.

[thaJeztah]

I'll copy @AkihiroSuda's LGTM 👍

ping @tonistiigi ptal

[cpuguy83]

Why not add a CloseRead to the pipe implementation?

[cpuguy83]

Doing nothing on CloseRead doesn't seem right.

[andrey-ko]

Not really directly related to theses changes, but it looks like that defer cancel() doesn't always close conn. So we can return from runDialStdio function without waiting or canceling background goroutines, for example if we read non-nil error from stdin2conn channel or anything from conn2stdout. Is it right behaviour? In case if we should cancel all background goroutines and close connection on exit, then nop-closeReader actually is ok, as it will always be followed by connection close call, but all this logic is quite obfuscated though...

[silvin-lubecki]

SGTM

[ijc]

Why not add a CloseRead to the pipe implementation?

I lack the necessary Windows background to make that happen. /cc @jstarks who added CloseWrite to these things in case he can help.

Doing nothing on CloseRead doesn't seem right.

This was @AkihiroSuda's suggestion in #1710 (comment), it seemed reasonable to me for objects which didn't support CloseRead.

#1710 has now been merged so my immediate problem is solved, I'm happy to bump this and address review around this basic premise etc but I'm unlikely to implement CloseRead on named pipes any time soon.

[ijc]

I've rebased (to pickup #1728 e2e fix) so this now includes the revert of #1710 too.

[ijc]

It turns out that system dial-stdio is also broken with tcp:// and --tls even on Linux:

$ ./build/docker-linux-amd64 -D -H tcp://18.197.174.153:443 --tls --tlscacert /tmp/tmp.TDp4Lrmnc1/ca.pem system dial-stdio DEBU[0000] conn is a *tls.Conn DEBU[0000] conn is a halfReadCloser: false DEBU[0000] conn is a halfWriteCloser: true the raw stream connection does not implement halfCloser

This PR helps with that too.

[AkihiroSuda]

Perhaps Close() should be called when both CloseRead() and CloseWrite() are called

[cpuguy83]

Go 1.11 should have CloseRead now for tls, as I recall.

[ijc]

Go 1.11 should have CloseRead now, as I recall.

Not according to https://golang.org/pkg/crypto/tls/, nor the test shown above which was with g1.11.

Perhaps Close() should be called when both CloseRead() and CloseWrite() are called

Not sure about that, since I don't have enough insight into what all the actual underlying objects might actually be.

OTOH -- shouldn't there be a conn.Close somewhere (perhaps deferred) in this function somewhere? Otherwise what is closing the conn in the end? Are we leaking an fd?

[AkihiroSuda]

defer conn.Close here?

[ijc]

Seems plausible and WFM in my simple cases, so I've pushed. I think this was just a preexisting leak, but it also help allay concerns about the nopCloseReader here too.

Would be good to get this tested with your ssh:// use case though.

[cpuguy83]

Oh that was CloseWrite that was added. I suppose it seems ok to just close when the reader is done. Brian Goff

…

On Mar 12, 2019, at 06:53, Ian Campbell ***@***.***> wrote: Go 1.11 should have CloseRead now, as I recall. Not according to https://golang.org/pkg/crypto/tls/, nor the test shown above which was with g1.11. Perhaps Close() should be called when both CloseRead() and CloseWrite() are called Not sure about that, since I don't have enough insight into what all the actual underlying objects might actually be. OTOH -- shouldn't there be a conn.Close somewhere (perhaps deferred) in this function somewhere? Otherwise what is closing the conn in the end? Are we leaking an fd? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[cpuguy83]

The alterntive here would be to always wrap and have an implementation that does

func(c*connWrapper) CloseRead() error {
ifrc, ok:=conn.(halfReadCloser) {
rc.CloseRead()
}
returnnil
}

I feel like the attach code does something like this.

But LGTM.

[thaJeztah]

Let's merged 👍