Shutdown grace period - wait for all players to disconnect
jemand771 opened this issue · comments
Introduction
I'm using itzg/docker-minecraft-server's amazing STOP_SERVER_ANNOUNCE_DELAY to gracefully stop minecraft servers on node shutdown.
Together with k8s' graceful node shutdown, this allows me to reboot a node running minecraft servers without worrying about anything:
- (if I'm feeling nice) tell people I'll do some maintenance
systemctl reboot- kubelet inhibits node shutdown and starts evicting pods (this respects pods' grace periods defined in their manifests)
- minecraft server gets sigterm, announces shutdown to players; saves and shuts down after 30s
- kubelet evicts cluster-critical pods (interesting if storage is "running" on the cluster, e.g. using longhorn)
- kubelet is done evicting, allows system to shutdown
- node restarts
- profit
Feature request
There's one step left to make this workflow perfect: mc-router currently exits as soon as it receives the request to do so (sigterm).
Because of this, even if the minecraft server itself does its neat shutdown sequence, mc-router immediately disconnects all players and stops. The minecraft server still gets saved properly (most important part to me), but players still get insta-kicked.
This isn't ideal and I'd love a way have it shut down not as violently if players are still online
Possible solutions
a) Static delay (configurable via env var/cli flag/...) - mc-router waits a certain number of seconds before stopping after it receives a signal (meh, but easiest)
b) Infinite delay - mc-router never stops on sigterm and instead relies on k8s' grace period to just get killed after some time (doesn't require mc-router configuration, instead uses kubernetes-side grace period. this may be problematic for other kinds of deployments (afaik docker has a similar concept to container stop -> kill grace periods, but it's somewhat cumbersome to use))
c) The smart way - mc-router waits until all players have disconnected until it shuts down. this can be combined with either a or b to prevent it from blocking indefinitely
Additional info
I'm not sure if this is possible given that mc-router doesn't do as much "player magic" as bungeecord, waterfall, and the like (which I love). As far as I understand it, it should still have some kind of connection list to base its behaviour on though.
Great idea and great write up. Option c looks quite doable and makes a lot of sense for all deployment scenarios. It doesn't currently keep a list of active connections but that or an active count will be easy to add.
This feature is now released in https://github.com/itzg/mc-router/releases/tag/1.16.1
wow, that was quick :D
works like a charm, thanks!