grpc/transport: unwanted stderr chatter using cloud.google.com/go APIs

[rsc]

I have a simple command-line tool that sets up a cloud.google.com/go/datastore client, does a Get, lets me edit the file in a text editor, does a Put. Nothing complex. I was running it and while I was editing (taking my time), I got this printed in my terminal:

2017/01/09 22:09:30 transport: http2Client.notifyError got notified that the client transport was broken EOF.

This print is making my nice command-line tool generate confusing output. Can this print please be silenced? I note the tests say:

te.declareLogNoise("transport: http2Client.notifyError got notified that the client transport was broken")

That wouldn't be needed if the print wasn't there at all. At the very least it should not be on by default.

Thanks.

[menghanl]

After #922, we will update log printings in gRPC to use different log levels.
This issue should be solved then.

[F21]

I don't know if this is related. I have a grpc server and client running for an end-to-end test.

After starting the client and asking it to connect to localhost:443, I get these errors:

2017/01/12 09:13:15 transport: http2Client.notifyError got notified that the client transport was broken EOF.
2017/01/12 09:13:15 grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: dial tcp [::1]:443: getsockopt: connection refused"; Reconnecting to {localhost:443 <nil>}
2017/01/12 09:13:16 grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: dial tcp [::1]:443: getsockopt: connection refused"; Reconnecting to {localhost:443 <nil>}
2017/01/12 09:13:18 grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: dial tcp [::1]:443: getsockopt: connection refused"; Reconnecting to {localhost:443 <nil>}
2017/01/12 09:13:20 grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: dial tcp [::1]:443: getsockopt: connection refused"; Reconnecting to {localhost:443 <nil>}
2017/01/12 09:13:24 grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: dial tcp [::1]:443: getsockopt: connection refused"; Reconnecting to {localhost:443 <nil>}
2017/01/12 09:13:32 grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: dial tcp [::1]:443: getsockopt: connection refused"; Reconnecting to {localhost:443 <nil>}
2017/01/12 09:13:43 grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: dial tcp [::1]:443: getsockopt: connection refused"; Reconnecting to {localhost:443 <nil>}

The errors appear to be transient and the tests pass fine. I tried adding a time.Sleep() after starting the server, but I always get those in the logs, no matter how long the duration is.

[aseure]

I'm experiencing the exact same error message as @rsc by using cloud.google.com/go/storage for writing files to Google Cloud Storage. It only happens from time to time and doesn't seem to impact the write operations in any way.

What is the exact meaning of this error?

[MakMukhi]

If an error occurs on the transport (the tcp connection), this error message is logged. If the error were transient the monitor routine reconnects.

…

On Fri, Jan 27, 2017 at 9:31 AM, Anthony Seure ***@***.***> wrote: I'm experiencing the exact same error message as @rsc <https://github.com/rsc> by using cloud.google.com/go/storage for writing files to Google Cloud Storage. It only happens from time to time and doesn't seem to impact the write operations in any way. What is the exact meaning of this error? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1044 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ATtnRxoFfKCdmOqeX2uSrB6_A-u7ODtjks5rWinngaJpZM4Le_Wu> .

[junghoahnsc]

I'm also seeing this error message while using gcloud pubsub.
But after this error occurs, the subscriber stops pulling a new message.
Should pubsub library handle this error? Or does the grpc reconnect automatically?

[hsaliak]

@menghanl assigning this back to you for the fix of #922

[peterbourgon]

I encountered this message when using the Stackdriver Logging client library. It was very surprising, because I gave no config or param to the logging.NewClient constructor that would indicate I've given it permission to write to my console. From my perspective, the problem is that package grpclog declares and uses a global log.Logger that writes to stderr.

I worked around it by stubbing out a no-op grpclog.Logger and swapping it in with SetLogger, but I shouldn't have to do that: packages should not log, and especially not to stdout/stderr directly; only package main has the right to decide what gets routed there. Instead, packages should take loggers (or event callbacks) as parameters, and leave the decision on what to do with the events to the caller.

IMO, the best possible resolution here would be for each exported type that wants to log (e.g. cloud.google.com/go/logging.Client) to have a functional option that sets a Logger callback. By default, logs should go to /dev/null.