query server shuts down if queried too early

[sheimer]

if i request a status right after i started a world, the query server quits and does not start again.

i changed "msctl", lines 1814 to 1815 are added:

1808   if [ -n "$RESPONSE" ]; then
1809     # Return the response in the format requested.
1810     $PERL -e '
1811       $packed = join "", map { pack ("C", hex($_)) } ("'$RESPONSE'" =~ /(..)/g);
1812       printf "%s\n", join "\t", unpack ("'$4'", $packed);
1813     '
1814   else
1815     ps a | grep socat | grep "$1" | grep tail >/dev/null || queryStart "$1"
1816   fi

with that change i dont have to restart the whole world again to get the query server up and running again, and after one "restart by additional queryStart" i can immediately use query or status again, without the server shutting down.

i intend to request the status right after world starting, since i write a web app to control the mscs script, so it would be very nice to have this extra lines in the repository :)

sorry for writing this as an issue, i dont know how to open a merge request...if you need more information about the query server shutting down in the first place, feel free to ask!

kind regards,

swen

[Jason M. Wood]

Hi @sheimer. Thanks for the patch! I'll have to find some time to give this a test

[Jason M. Wood]

I finally found some time to test this patch. It seems to work as expected, so I accepted the merge request. Sorry for taking so long to get to the review. Thanks for the patch.

[Roflicide]

What's the purpose of having an OR operator with ps a | grep socat | grep "$1" | grep tail >/dev/null ? Why not just take it out and simply have queryStart $1 ?

[sheimer]

there is a timeframe where the queryserver is starting, but still not responding. so in that timeframe you will get to the else part of the condition, and the part before the "or" prevents the query server to be started multiple times.

[Roflicide]

@sheimer Thanks, that makes sense! I think I realized why this issue was occurring in the first place after some debugging: the query port hasn't opened yet so the socat connection automatically drops. Your solution of reconnecting in the querySendPacket function definitely fixes the issue, but it's downstream from the initial issue and takes a bit of time and a few running (query server offline) responses before the query server gets back up. I'm going to try and fix the source issue (waiting until the query port opens before connecting socat) so we can get a quicker/more robust response