Accept loop has improper error handling, causing wrong exit code.

[hessjcg]

When the proxy receives a SIGTERM, it will close this server socket. This can result in the server.Accept() returning a non-nil error with the message "proxy server error: accept tcp" or "use of closed network connection". This error will be put into the error channel, causing the process end with exit code 2, instead of the appropriate 143 (TERMINATED) or 0 (SUCCESS).

See https://github.com/GoogleCloudPlatform/cloud-sql-proxy/blob/main/cmd/root.go#L1143

[hessjcg]

Still looking into this one.

[hessjcg]

Keeping this on the backlog for now. We would like to resolve it.

[eremeevfd]

@hessjcg thanks for opening the issue! we faced the same thing recently, did you find any workaround for now?

[eremeevfd]

okay sorry, I found an answer myself

My context is this: I'm using kubernetes and use cloud-sql-proxy in CronJobs, recently I've migrated just hosting a proxy in a container to a native sidecar (init container) and got a lot of errors, I thought it was related to the original reported error for SIGTERM, however I've missed that the proxy returns code 143 instead of 0 on SIGTERM, so I just needed to add a flag

--exit-zero-on-sigterm

to make it work properly

[hessjcg]

This is still a valid issue, but I'm moving it to a P3 for now since --exit-zero-on-sigterm works correctly under most circumstances.