Add option to suppress SignalException on SIGTERM #1690
Conversation
mic-kul
changed the title
|
Is this still a WIP? |
mic-kul
changed the title
|
Thanks for the reminder. Committed my recent changes and it's ready for another look @evanphx |
The exception is used by many libraries to clean up on SIGTERM. Firing that exception forces all the ensure blocks of the application to fire, for example telling libraries to safely close references to files etc. I don't have a problem with this being a configurable option, but I do worry about the unintended side effects of enabling this for long term system stability. |
|
@schneems I agree it has side effects - ie. Kafka buffers might not be flushed properly. I just couldn't understand why clustered mode raises it, while single mode does not. |
|
I think in single mode the exception would be raised directly by the process since it’s what gets the sigterm versus the code in clustered is designed to propagate the sigterm. I think anyway. |
`Puma` raises a `SignalException` on receiving a `SIGTERM` to kill the process puma was running on. While this is an expected behavior, deployments, especially for dockerized applications, usually use `SIGTERM` as a measure to kill processes. This results in our exception tracker receiving a lot of `SignalException` errors on every deploy. This small configuration change will suppress those errors. For more information please check this link: puma/puma#1690
`Puma` raises a `SignalException` on receiving a `SIGTERM` to kill the process puma was running on. While this is an expected behavior, deployments, especially for dockerized applications, usually use `SIGTERM` as a measure to kill processes. This results in our exception tracker receiving a lot of `SignalException` errors on every deploy. This small configuration change will suppress those errors. For more information please check this link: puma/puma#1690
This _should_ prevent the SIGTERM exceptions sent by Heroku to restart dynos from being re-raised by Puma after it's handled them. See puma/puma#1690 for more info.
What:
This PR adds config option to disable raising SignalException when SIGTERM is received.
Why:
When running Puma inside Docker container that is orchestrated by Kubernetes/Docker swarm/ECS or other container platform SIGTERM is something expected, usually instructing app to shut down gracefully. Rolling restart is handled by infrastructure / orchestrator itself.
SignalException should not be raised in this case.