starred/LinuxGSM

Fork 0

mirror of https://github.com/GameServerManagers/LinuxGSM.git synced 2026-04-25 22:25:59 +03:00

[GH-ISSUE #2302] Monitor function prevents the server from starting if it's in the process of starting #1736

New issue

Closed

opened 2026-02-27 02:58:47 +03:00 by kerem · 5 comments

kerem commented

2026-02-27 02:58:47 +03:00

Owner

Originally created by @haggbart on GitHub (Apr 24, 2019).
Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/2302

User Story

As a user, I want the monitor function to work correctly so that it will kill the server if it's not responding.

Basic info

Distro: Debian 9
Game: Rust
Command: Monitor

Further Information

If the server is in the process of starting, monitor will force kill the process and cancel start.
This happens because query_gsquery.py tries to querry the game port, which will not respond until the server has started. It should querry using the rcon port, which will respond while starting.

To Reproduce

Steps to reproduce the behaviour:

./rustserver start
./rustserver monitor
The script will kill the process, stopping the server from starting.
See attachement.

Expected behaviour

monitor function should kill the process if it's not responding

Originally created by @haggbart on GitHub (Apr 24, 2019). Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/2302 ## User Story As a user, I want the monitor function to work correctly so that it will kill the server if it's not responding. ## Basic info * Distro: Debian 9 * Game: Rust * Command: Monitor ## Further Information If the server is in the process of starting, monitor will force kill the process and cancel start. This happens because query_gsquery.py tries to querry the game port, which will not respond until the server has started. It should querry using the rcon port, which will respond while starting. ## To Reproduce Steps to reproduce the behaviour: 1. ./rustserver start 2. ./rustserver monitor 3. The script will kill the process, stopping the server from starting. 4. See attachement. ![yUc7dzb](https://user-images.githubusercontent.com/4412029/56646770-85e90a00-6680-11e9-9754-b9db03fb0f48.jpg) ## Expected behaviour monitor function should kill the process if it's not responding

kerem

2026-02-27 02:58:47 +03:00

closed this issue
added the
type: bug

command: monitor

priority
labels

kerem commented

2026-02-27 02:58:48 +03:00

Author

Owner

@dgibbs64 commented on GitHub (Apr 25, 2019):

I believe this is linked to another issue #2119 This is an issue I will look at addressing soon. Thanks for the detailed and accurate issue you raised.

@dgibbs64 commented on GitHub (Apr 25, 2019): I believe this is linked to another issue #2119 This is an issue I will look at addressing soon. Thanks for the detailed and accurate issue you raised.

kerem commented

2026-02-27 02:58:48 +03:00

Author

Owner

@kobalt-rustafied commented on GitHub (Jun 22, 2019):

@dgibbs64 Issue #2119 was closed and marked as fixed with v19.7.0. In our use case with rust servers, we are still having the exact same issue. Maybe I am misunderstanding but I thought the lock file should prevent the monitor from ever running a query until the query delay time has passed. In my experience, the query delay has no effect on it. I have also tried editing command_monitor.sh directly and adding in the query delay variable and it still had no effect on it.

@kobalt-rustafied commented on GitHub (Jun 22, 2019): @dgibbs64 Issue #2119 was closed and marked as fixed with v19.7.0. In our use case with rust servers, we are still having the exact same issue. Maybe I am misunderstanding but I thought the lock file should prevent the monitor from ever running a query until the query delay time has passed. In my experience, the query delay has no effect on it. I have also tried editing command_monitor.sh directly and adding in the query delay variable and it still had no effect on it.

kerem commented

2026-02-27 02:58:48 +03:00

Author

Owner

@kobalt-rustafied commented on GitHub (Jun 22, 2019):

@dgibbs64 I found the issue. In command_monitor.sh
if [ "$(cat "${rootdir}/${lockselfname}")" -lt "$(date "+%s" -d "${querydelay} mins ago")" ]; then
needs to be chnaged to
if [ "$(cat "${rootdir}/${lockselfname}")" -gt "$(date "+%s" -d "${querydelay} mins ago")" ]; then

This has fixed my issue, I hope it can help anyone else who may have the same issue.

@kobalt-rustafied commented on GitHub (Jun 22, 2019): @dgibbs64 I found the issue. In command_monitor.sh if [ "$(cat "${rootdir}/${lockselfname}")" -lt "$(date "+%s" -d "${querydelay} mins ago")" ]; then needs to be chnaged to if [ "$(cat "${rootdir}/${lockselfname}")" -**g**t "$(date "+%s" -d "${querydelay} mins ago")" ]; then This has fixed my issue, I hope it can help anyone else who may have the same issue.

kerem commented

2026-02-27 02:58:48 +03:00

Author

Owner

@h3o66 commented on GitHub (Jun 22, 2019):

just created a pr to fix this

@h3o66 commented on GitHub (Jun 22, 2019): just created a pr to fix this

kerem commented

2026-02-27 02:58:49 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Dec 25, 2020):

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

@github-actions[bot] commented on GitHub (Dec 25, 2020): This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.