For autopause, added use of mc-monitor to detect players connected #1059
Conversation
files/autopause/autopause-fcns.sh
Outdated
|
|
||
| mc_server_listening() { | ||
| [[ -n $(netstat -tln | grep -e "0.0.0.0:$SERVER_PORT" -e ":::$SERVER_PORT" | grep LISTEN) ]] | ||
| mc-monitor status --host localhost --port $SERVER_PORT >& /dev/null |
There was a problem hiding this comment.
Propose reverting this or adding an early-fail flag in mc-monitor (used only in initial state of autopause deamon)
There was a problem hiding this comment.
I don't fully understand the suggestion since that's what mc-monitor status is doing. It's used already for health checks.
There was a problem hiding this comment.
...oh you mean skipping timeout?
There was a problem hiding this comment.
Yes, skipping the timeout, I couldn't get the timeout command line flag to work (--retry-interval 1s --retry-limit 1 --timeout 1s was not timing our with the stopped process). In the healthcheck the process is also checked, as the healthcheck was spawning endless processes initially.
There was a problem hiding this comment.
Now I see what you mean and yes, this is not going to be acceptable. I'll play with tweaking the knockd config, since running mc-monitor via the debugger externally causes the knock to kick in. This also makes me realize that the mc-monitor approach is really only useful during running state to detect zero players.
There was a problem hiding this comment.
imo, this won't be solved by knockd, this function is only used to switch from deamon init state to the initial timeout state, so the process isn't stopped here, it's waiting for the server to listen for connections (where exactly it does that during startup is another question, especially wrt modding)
There was a problem hiding this comment.
I didn't mean to imply knockd would solve this. I was just thinking out loud that I needed to temporarily change my container's config to let me recreate the blocked ping operation.
The server binds the listening port at the very end of startup, so it's a very robust (even with mods) way to know when the server is ready.
There was a problem hiding this comment.
FYI, have a PR open for the issue I found raqbit/mc-pinger#14
There was a problem hiding this comment.
my bad, didn't know that this failure to TO was strictly related to the paused process, I was only using mc-monitor from inside the image, Checking with the pure monitor docker image to a nonexisting server, I agree with this change and understand your previous comments.
|
@Oekn5w did you notice problems during testing? It all seemed to work fine for me, but I might have missed something since I'm not used to using the feature. |
|
Pausing and unpausing works fine for Java clients, cannot test for Geyser |
Co-authored-by: Michael Kirsch <mkirsch.git@gmail.com>
Oekn5w
left a comment
Oekn5w
left a comment
There was a problem hiding this comment.
the initial up detection is still open imo
I'm open to more data on why it's not sufficient. If this is flawed, then the whole container readiness approach is flawed. |
# Conflicts: # Dockerfile
|
mc-monitor 0.10.1 now properly times out when contacting a paused server |
|
@kjburr can you test this image with Geyser and bedrock clients? |
|
Works well. The only issue I found is If a bedrock client is left open at the main menu or inside the play menu it will knock and pause repeatedly. It was listed under LAN games though not sure if that makes a difference. Java has a refresh button for servers and bedrock does not so I'm guessing it just constantly pings. |
|
Very glad to hear @kjburr. I know the bedrock client at least does periodic multicast packets, so that would make sense to then induce a knock on the java side. I'll get this merged soon. |
Image is available for testing
itzg/minecraft-server:test-auto-pause-use-mc-monitorcc @Oekn5w @kjburr
Closes #1046