Proxy exits with wrong code after SIGTERM

[cdaguerre]

Bug Description

Graceful termination seems impossible in v2. Whether I set --max-sigterm-delay or not doesn't matter, process always has exit code 137, even when there are no active connections.

Example code (or command)

- name: cloudsql-proxy
  image: {{ $root.Values.sqlProxy.image }}
  command:
    - '/kubexit/kubexit'
    - '/cloud-sql-proxy'
    - '--address=127.0.0.1'
    - '--max-sigterm-delay=10s'
    - '--structured-logs'
    - '--prometheus'
    {{- range $k, $v := $root.Values.sqlProxy.connections }}
    - '{{ $v.dsn }}?port={{ $v.port }}'
    {{- end }}
  lifecycle:
    preStop:
      exec:
        command: ['sleep', '10']

Stacktrace

How to reproduce

1. ?
2. ?

Environment

1. OS type and version: GKE 1.24.4-gke.800
2. Cloud SQL Proxy version (./cloud-sql-proxy --version): 2.0.0-preview.2

[enocom]

Thanks for the issue @cdaguerre.

Looking at these exit codes again, I see that SIGTERM is conventionally 143 and SIGKILL is 137.

I think what this means is that we should be returning exit code 143 instead of 137 here: https://github.com/GoogleCloudPlatform/cloud-sql-proxy/blob/main/cmd/errors.go#L29.

Cf. https://komodor.com/learn/sigterm-signal-15-exit-code-143-linux-graceful-termination/

Is that your expectation?

[cdaguerre]

Hey @enocom
Actually in v1, even when the proxy received a SIGTERM, the exit code would be 0 if there were no more active connections.
The use case is for running the proxy as a sidecar in kubernetes Jobs that run to completion.
You need to have a way to kill the cloudsql-proxy sidecar container when the main container finished.
Any exit code other then 0 from one of the containers causes the job to be considered failed.

Basically, ideal behaviour to gracefully terminate on SIGTERM taking the --max-sigterm-delay into account.

• Exit 0 as soon as there is no active connection anymore
• After sigterm delay,
  • exit 137 (SIGKILL) if there is an active connection
  • exit 0 if there is no active connection (probably already exited before delay...)

EDIT: added link to v1 code:

cloud-sql-proxy/proxy/proxy/client.go

Line 630 in 6af6a92

// Shutdown waits up to a given amount of time for all active connections to

[enocom]

Thanks for the clarification.

There are two issues here:

1. The v2 proxy uses the wrong exit code for SIGTERM. We'll fix that here.
2. There's no way to cleanly shutdown the proxy without some wrapper script. That's tracked here: Provide a way to shutdown the process from another container #828.

Since we've made this worse in v2 with the new non-0 exit code, I'll prioritize adding a /quitquitquit endpoint to solve this.