cloud-sql-proxy: SIGTERM with no active connections should result in 0 exit code
Feature Description
We have an issue where airflow detects non-zero exit code as a problem in KubernetesPodOperator. Digging deeper to the recent changes in V2 it seems like we moved from 0 to 143 in the case of sigterm.
However this behaviour is curious when all connections etc are gracefully terminated within the time period. There is really no issue so shutdown should result in 0 (imho).
Whats the reasoning behind having 143 always?
Sample code
No response
Alternatives Considered
I was reading https://github.com/GoogleCloudPlatform/cloud-sql-proxy/issues/1529#issuecomment-1308118348 and would like to avoid /quitquitquit. And I also cant really figure out why using the endpoin is ‘better’ than SIGTERM?
Additional Details
No response
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 21 (11 by maintainers)
I’m open to adding a flag to configure this behavior. It seems the most pragmatic.
How about this?
We’ll have this out in the next release on Tuesday.
We’ll still add a flag to exit zero on sigterm separately here, but that will probably be in the following release (next month).
@enocom great! Thank you so much! Can’t wait, no more failed pods in k8s!
See here for confirmation: https://github.com/GoogleCloudPlatform/cloud-sql-proxy/blob/main/cmd/errors.go#L34.
I believe that’s just where the error message is going which we’ve fixed here: https://github.com/GoogleCloudPlatform/cloud-sql-proxy/pull/1806. We’ll have this out in the next release on Tuesday.