You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're using the image tag timescale/timescaledb-ha:pg13.16-ts2.15.3 with Patroni and since the last update to that tag (which came with an upgrade to Patroni 4.0.2 and the STOPSIGNAL change from SIGTERM to SIGINT, see #492) the "delete/stop" commands from Kubernetes don't lead to a graceful shutdown anymore. Within the pods / processes nothing happens and then it's forcefully killed after the terminationGracePeriodSeconds.
Here are the relevant processes running inside the pod for a replica of a three node HA setup
When sending a SIGINT to PID 1 or 15 nothing happens (also simulated this with kill -s SIGINT <PID>). When looking into the auditd logs of the host machine you see that PID 1 receives the SIGINT but PID 15 doesn't. When sending a SIGTERM everything works as expected.
We first thought it might be a problem with Patroni but the guys over in the Patroni Slack couldn't reproduce it and also our internal tests with this setup https://github.com/patroni/patroni/tree/master/docker confirm, that Patroni works as intended there.
Hope you can help. If you need more information don't hesitate to ask :)
Have a great weekend
The text was updated successfully, but these errors were encountered:
Hey Team :)
We're using the image tag
timescale/timescaledb-ha:pg13.16-ts2.15.3
with Patroni and since the last update to that tag (which came with an upgrade to Patroni 4.0.2 and the STOPSIGNAL change from SIGTERM to SIGINT, see #492) the "delete/stop" commands from Kubernetes don't lead to a graceful shutdown anymore. Within the pods / processes nothing happens and then it's forcefully killed after theterminationGracePeriodSeconds
.Here are the relevant processes running inside the pod for a replica of a three node HA setup
When sending a SIGINT to PID 1 or 15 nothing happens (also simulated this with
kill -s SIGINT <PID>
). When looking into the auditd logs of the host machine you see that PID 1 receives the SIGINT but PID 15 doesn't. When sending a SIGTERM everything works as expected.We first thought it might be a problem with Patroni but the guys over in the Patroni Slack couldn't reproduce it and also our internal tests with this setup https://github.com/patroni/patroni/tree/master/docker confirm, that Patroni works as intended there.
Hope you can help. If you need more information don't hesitate to ask :)
Have a great weekend
The text was updated successfully, but these errors were encountered: