Improving the monitor function

[JimTR]

The web interface checks on load if the server is running via checking a) there is a tmux session for the server and a query to the server (via php gameq api ) if both are true we are running ... so if tmux = true & gameq = false = dead server, if dead run 'server file monitor' on the server however 'server file monitor' returns however the server is still crashed

to fix this I have to send the restart command rather than the monitor command ... so how is monitor returning OK when in it has really crashed ? Note: This is one of the last functions to adjust but currently is totally stock

[dgibbs64]

The monitor query's the server port using gsquery.py https://github.com/dgibbs64/linuxgsm/blob/master/GameServerQuery/gsquery.py gsquery returns an ok or fail.

[JimTR]

It does not appear to work gsquery is returning OK but the server has crashed ... is gsquery probing the server enough ?

[UltimateByte]

Sometimes a server answers to query even if the engine isn't responding. It doesn't happen often, but it happens.

[JimTR]

I get it every time the web code shows the server crash(image 2 thin blue line at the top) ... however this only happens on Garrys mod and the console reports a segmentation error ... so maybe gsquery needs to probe the server like gameq does (gameq asks the server for loads of info & fails a different way to gsquery)

[UltimateByte]

Segmentation fault is supposed to auto reboot the server. Did you disable autoreboot ?

[UltimateByte]

Please, also note this issue with gmod that isn't corrected yet. https://github.com/Facepunch/garrysmod-issues/issues/2342

[JimTR]

no I did not disable it the segmentation fault occurs while the server is running (no interaction i.e no quit command sent) fair enough Gmod issue. The point is when gsquery interacts it thinks the server is running and not failed

[JimTR]

unless a player sent the quit command ?

[UltimateByte]

The quit command (used by "stop" and ofc "restart" functions of the script) makes a segmentation faut, then if autorestart is enable (by default it's ON) it automatically restarts, without the help of the script, and still within the tmux session. I've been playing around with that crap to understand the gmod bug i just linked. :o)) So if you made a stop command, then the server doesn't shutdown, so it will do a graceful shutdown (kill the process) after 30 seconds. I think that this may have been corrected already, because now, servers i reboot show graceful restart for 1 or 2 secs, the time to close properly. So your issue is probably here. That is i guess all there is to know about the quit command doing a segmentation fault.

Is your issue an "all the time" issue, or did it only happen once or a few times ? If it happened a few times, then i think it's the issue i told you about before : Server still responds to ping, you can even sometimes try to connect to it, BUT CAN'T finalize loading or play properly on it.

As you say "so maybe gsquery needs to probe the server like gameq does (gameq asks the server for loads of info & fails a different way to gsquery)", but i'm not even sure it would be enough for gmod. Keep in mind that this game is a bug itself. At least it feels like that to me, after about 8 years playing to it :o))

BTW, are you talking about this ? https://github.com/Austinb/GameQ

[JimTR]

Yep GameQ .. works well ... but I guess my server fails through players maxing it out which then puts linux instance into 'hunt for memory' which equals segmentation error. The error still is gsquery does not pick this up & returns the server as 'online' gameq on the other hand returns the server offline (which is correct).

[UltimateByte]

I don't know python at all, but from the gsquery.py, i guess it sends a query string to the game on the right IP and the right port. https://github.com/dgibbs64/linuxgsm/blob/master/GameServerQuery/gsquery.py

Do you have any idea how GameQ is working to consider an upgrade to gsquery.py ? BTW, gsquery has to be reworked so that would be a good combination to either make it a function and improve the querying. https://github.com/dgibbs64/linuxgsm/issues/567

But as we both had this issue with gmod only, i personally consider this as a low priority issue to fix, more due to the unstability of gmod than to the script.

[JimTR]

Ok gameq is dead simple to use via PHP & returns, on/off line, a player list, current map, total players connected and a load more ... so it would not be too difficult to write a php wrapper around the gameq api which could be called from a bash script or perhaps, if python supports it, an exec from python ?

[UltimateByte]

This could be an extension to LGSM supported again with the skeleton directory. https://github.com/dgibbs64/linuxgsm/issues/585 I personally don't have the knowledge to make it.

[UltimateByte]

Any idea how to improve it using bash or python rather than an external script ? Rcon query is a good idea https://github.com/dgibbs64/linuxgsm/issues/299

[JimTR]

I have code running using gameq wraped in some bash code to integrate it into LSGM ... I have fn_gameq which runs what I need ... however I have looked at gsquery.py and it responds with the server up when its actually in un recoverable error ... a good response is like : OK: ����ILightSound Garrys Mod Strandedgms_rollinghills_daynight_b1garrysmodGarry's Mod Stranded�
dl
15.12.15��i�~|@
gm:gmstranded gmws:133364818� : I am waiting for a server crash to see what the difference is

[UltimateByte]

Thanks for the feedback, this will need to be investigated a bit more.

[jaredballou]

Well this just ate up a good portion of my night. Hard to let it go, and can't get my tools working the way I'd like. But I'm of the same mind, as neat as gsquery.py is if we could put that functionality into Bash and remove the dependency on Python, I think that might be a good thing. I have a few things that may be useful here.

For rcon, I have a Bash script that worked in the past but now seems b0rked. https://github.com/jaredballou/insurgency-tools/blob/master/utilities/bin/rcon.sh

As far as PHP, I use the steam-condenser-php library to allow me to query servers. https://github.com/jaredballou/steam-condenser-php I have a simple script that then queries servers, and then checks the Steam API to ensure that the servers are up to date. https://github.com/jaredballou/insurgency-tools/blob/master/server.php

Also for PHP is a much simpler rcon-only class at https://fremnet.net/article/199/source-rcon-class which works.

Rcon binary message format is this:

\0\0 size. packet_id and serverdata are all 32-bit signed longs. size if the binary size of everything from the packet id to the end of the message. command and unused are strings. The null characters in the middle of the string are really making Bash parsing difficult here, so unless someone is better at packing/unpacking binary data, we may have a good reason to switch to Python here. Or, stay with it, as it were. Also, Valve's RCON protocol wiki: https://developer.valvesoftware.com/wiki/Source_RCON_Protocol

[UltimateByte]

@jaredballou I'm not sure to see the point. You wanna remove dependency to python, while adding external bash and php scripts ? I don't think it's working unless we can write a simple bash script that does that. Is that really the only way to improve the monitor function ?

[UltimateByte]

Would be very kind to give your final thoughts right here : https://github.com/dgibbs64/linuxgsm/issues/567 and to close this one, as it's kinda duplicate. I'm closing for now, feel free to re-open if your thoughts are a bit complicated to summ up right now. But please, keep in mind that calling external code for a very important core function such as monitor, is probably not the best idea. I don't wanna speak in the name of dgibbs, but i think it would be better to have our own code, that is simple and fully understandable, so we can maintain and fix it easily if it gets broken at any time.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.