Cloudsql-proxy: New connection for "myproject:region:db". Client closed local connection on 127.0.0.1:5432

Created on 6 Jul 2018  Â·  18Comments  Â·  Source: GoogleCloudPlatform/cloudsql-proxy

Our app was deployed at GKE according to https://cloud.google.com/sql/docs/postgres/connect-kubernetes-engine.

The deployment includes 2 containers myapp + cloudsql-proxy. As app server boots, myapp have no any errors but cloudsql-proxy.

The following errors from cloudsql-proxy:

New connection for "myproject:region:db".
Client closed local connection on 127.0.0.1:5432

any idea? @Carrotman42

Thanks.

Most helpful comment

We are facing the same problem. Proxy based connection is printing error log messages(connection open and close). Our log based metrics are getting effected.
Why this cannot be fixed?

Ideally we would want to use proxy but we are falling back to private IP solution.
We believe this is a fixable issue.

All 18 comments

Those are not error messages, they are just informational. It comes out of
stderr because that's where Go standard logging logs end up. There are
command line flags to control/suppress these logs if you don't like them.

On Thu, Jul 5, 2018, 8:51 PM kevin-jj notifications@github.com wrote:

Our app was deployed at GKE according to
https://cloud.google.com/sql/docs/postgres/connect-kubernetes-engine.

The deployment includes 2 containers myapp + cloudsql-proxy. As app server
boots, myapp have no any errors but cloudsql-proxy.

The following errors from cloudsql-proxy:

New connection for "myproject:region:db".
Client closed local connection on 127.0.0.1:5432

any idea? @Carrotman42 https://github.com/Carrotman42

Thanks.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/cloudsql-proxy/issues/190, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAiy732NcBgJN8I9Bg8_53GvJUUbQGWrks5uDt7TgaJpZM4VE1_Z
.

Sorry, I am unable to interpret the image you posted, I am unfamiliar with GKE. But it seems you closed the issue so maybe you figured out what was wrong? Please reopen if there's anything we can do to help.

Yes, I have figured out that the issue was caused by our K8S configuration file. Cloudsql-Proxy has no problems. Thanks @Carrotman42

Awesome, thanks for the confirmation!

Yes, I have figured out that the issue was caused by our K8S configuration file. Cloudsql-Proxy has no problems. Thanks @Carrotman42

What did you do that made it go away please?

What did you do that made it go away please?

If you are running 1.13, you can add the following to your startup: -log_debug_stdout=true

Getting this when I set the flag: flag provided but not defined: -log_debug_stdout

Getting this when I set the flag: flag provided but not defined: -log_debug_stdout

150 was included in 1.13. Are you sure you are running 1.13?

Oh.

Can I upgrade? How do I upgrade please.

@casoetan You can download the latest version on the Releases page.

@kevin-jj what kind of configuration was wrong?

@kurtisvg, I mean upgrade my GKE to use the upgrade?

@kevin-jj what kind of configuration was wrong?

We was booting a daemon process of PUMA at app server so that K8S closed the process of PUMA and cloud-proxy. @vongohren

@casoetan If you are using GKE, just update the gcr.io url in your deployments config. GKE should pull the newer version the next time the pod is deployed

same issue. Don't know why. Any one can explain it ?

@mrdulin I think you have to look at your client library and look at what might happen there. Because that can be the culprit, like this issue https://github.com/GoogleCloudPlatform/cloudsql-proxy/issues/243

We are facing the same problem. Proxy based connection is printing error log messages(connection open and close). Our log based metrics are getting effected.
Why this cannot be fixed?

Ideally we would want to use proxy but we are falling back to private IP solution.
We believe this is a fixable issue.

@mothukuri any reason you prefer proxy but not private IP? Our experience with proxy is mixed. Sometimes the connection is quite unstable. Luckily our application can connect to db through private IP.

Was this page helpful?
0 / 5 - 0 ratings