Stopping puma with Systemd takes too long
User Story
After upgrading Puma to version 5.0 in pull request #5178, which requires systemd (or a similar system), we've noticed that, on our staging server, stopping (or restarting) the Puma service with Systemd takes exactly 60 seconds (it used to take exactly 90 before we started using a Puma socket in pull request #5372).
This means requests to a Consul application might timeout while restarting Puma after deploying new code.
We haven't found the cause yet. We've tried using Type=notify in the systemd service, or upgrading to Puma 6, getting the same results.
Quick clarification on the timeout behavior: Have you tried:
systemctl show --property=DefaultTimeoutStopUSec
TimeoutStopSec?
Hi, @hooiv :smile:.
It shows 1min 30s indeed. I'm not sure about lowering it, though; would rather find out why it doesn't stop until reaching the timeout 🤔. Might be a possible workaround, though, so thanks for the suggestion! If you've got any other ideas, please let us know :wink:.