Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sshforward: skip conn close on stream CloseSend. #3431

Merged
merged 1 commit into from
Dec 21, 2022

Conversation

sipsma
Copy link
Collaborator

@sipsma sipsma commented Dec 21, 2022

The GRPC docs on RecvMsg say:

RecvMsg blocks until it receives a message into m or the stream is
done. It returns io.EOF when the client has performed a CloseSend.
On any non-EOF error, the stream is aborted and the error contains
the RPC status.

So if EOF is received that just means the client won't be sending anymore data. But it may still be expecting to read data, so we shouldn't close the conn yet.

This was encountered in real life when forwarding a docker socket to a container, where it appears that the docker CLI closes its write side of the connection after requesting the stdout/stderr stream of a container but then expects to read data after that.

Signed-off-by: Erik Sipsma [email protected]

Related issue in dagger: dagger/dagger#4073

The GRPC docs on RecvMsg say:
> RecvMsg blocks until it receives a message into m or the stream is
> done. It returns io.EOF when the client has performed a CloseSend.
> On any non-EOF error, the stream is aborted and the error contains
> the RPC status.

So if EOF is received that just means the client won't be sending
anymore data. But it may still be expecting to read data, so we
shouldn't close the conn yet.

This was encountered in real life when forwarding a docker socket to a
container, where it appears that the docker CLI closes its write side of
the connection when requesting the stdout/stderr but then expects to
read data after that.

Signed-off-by: Erik Sipsma <[email protected]>
@sipsma sipsma merged commit de7dd7a into moby:master Dec 21, 2022
@tonistiigi tonistiigi mentioned this pull request Jan 6, 2023
aaronlehmann added a commit to aaronlehmann/buildkit that referenced this pull request Jan 13, 2023
PR moby#3431 caused connections closed on the remote side of a sshforward
session to not always result in the local side reading an EOF from the
connection. This change restores that behavior by closing the write side
of the forwarded connection after reading an EOF from the stream. Since
only the write side is being closed, it doesn't prevent the remote side
from continuing to read from the connection.
aaronlehmann added a commit to aaronlehmann/buildkit that referenced this pull request Jan 13, 2023
PR moby#3431 caused connections closed on the remote side of a sshforward
session to not always result in the local side reading an EOF from the
connection. This change restores that behavior by closing the write side
of the forwarded connection after reading an EOF from the stream. Since
only the write side is being closed, it doesn't prevent the remote side
from continuing to read from the connection.

Signed-off-by: Aaron Lehmann <[email protected]>
aaronlehmann added a commit to aaronlehmann/buildkit that referenced this pull request Jan 14, 2023
PR moby#3431 caused connections closed on the remote side of a sshforward
session to not always result in the local side reading an EOF from the
connection. This change restores that behavior by closing the write side
of the forwarded connection after reading an EOF from the stream. Since
only the write side is being closed, it doesn't prevent the remote side
from continuing to read from the connection.

Signed-off-by: Aaron Lehmann <[email protected]>
tonistiigi pushed a commit to tonistiigi/buildkit that referenced this pull request Jan 17, 2023
PR moby#3431 caused connections closed on the remote side of a sshforward
session to not always result in the local side reading an EOF from the
connection. This change restores that behavior by closing the write side
of the forwarded connection after reading an EOF from the stream. Since
only the write side is being closed, it doesn't prevent the remote side
from continuing to read from the connection.

Signed-off-by: Aaron Lehmann <[email protected]>
(cherry picked from commit 8c978cf)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants