[GH-ISSUE #1886] Improving concurrent commands with lockfiles #1480

New issue

Open

opened 2026-02-27 02:57:21 +03:00 by kerem · 2 comments

kerem commented

2026-02-27 02:57:21 +03:00

Owner

Originally created by @UltimateByte on GitHub (Apr 18, 2018).
Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/1886

We could use more lockfiles, and these lockfiles could use timings to prevent stuff from happening too soon or at the same time (say with bad crons, or when you run a crons + the same function at the same time).

Consider the server start delay

A server that was just started will not answer to queries, sometimes for a while (Rust takes ages to start, the game could be downloading workshop content, etc.). If the server is not responding for some valid reason, you do not want it to bootloop.

Regarding this:

Monitor could use the date of the game server instance's lockfile, so that if it was started less than 5 minutes ago (by default), it will close the monitor function after 10 seconds, unless the user types "y" to override this and runs monitor anyways.
We need to make sure the date is updated in case of a restart using monitor (maybe it is already the case)

You don't want to run two monitor at the same time, and you'd love to restart the server as fast as possible if it does not answer to queries.
After the first fix has been implemented, we can now add multiple improvements.

Monitor could have a lockfile, so two monitor cannot run at the same time
Since we waited for the server to be started, if it does not answer to queries, monitor does not need to wait for too long if the server is not answering to queries. The default value could be 10 seconds (10 failed queries), and we could also add a parameter for the user to increase that if his server lags a lot.
If a monitor lockfile is more than 5 minutes, then this is probably a residue of an interrupted monitor, and the lockfile should be removed, and monitor ran anyways.

With this in place, users could run the monitor cronjob every minute without any issues.

You don't want multiple updates to run at the same time

Update and validate commands could use the same lockfile, used to prevent from running two times the functions at once
If the lockfile is more than 1h, then it should be removed and the update should run anyway.
Mods-update could also benefit from its lockfile.

Move lockfiles checks to its own function

Since we are now running multiple lockfiles, it would be wise to use a check script for that purpose, for example check_lockfile.sh, which would be run using check.sh for relevant commands.
We should not forget FastDL command which uses a lockfile as well.
All these lockfiles could use the jail method that we are already using, to remove the lockfiles in case of a script interruption by the user (kill or ctrl +c).

That's all I can think about for now. If you have more ideas for lockfiles, please share.

Originally created by @UltimateByte on GitHub (Apr 18, 2018). Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/1886 We could use more lockfiles, and these lockfiles could use timings to prevent stuff from happening too soon or at the same time (say with bad crons, or when you run a crons + the same function at the same time). 1) **Consider the server start delay** A server that was just started will not answer to queries, sometimes for a while (Rust takes ages to start, the game could be downloading workshop content, etc.). If the server is not responding for some valid reason, you do not want it to bootloop. Regarding this: - Monitor could use the date of the game server instance's lockfile, so that if it was started less than 5 minutes ago (by default), it will close the monitor function after 10 seconds, unless the user types "y" to override this and runs monitor anyways. - We need to make sure the date is updated in case of a restart using monitor (maybe it is already the case) 2) **You don't want to run two monitor at the same time, and you'd love to restart the server as fast as possible if it does not answer to queries.** After the first fix has been implemented, we can now add multiple improvements. - Monitor could have a lockfile, so two monitor cannot run at the same time - Since we waited for the server to be started, if it does not answer to queries, monitor does not need to wait for too long if the server is not answering to queries. The default value could be 10 seconds (10 failed queries), and we could also add a parameter for the user to increase that if his server lags a lot. - If a monitor lockfile is more than 5 minutes, then this is probably a residue of an interrupted monitor, and the lockfile should be removed, and monitor ran anyways. With this in place, users could run the monitor cronjob every minute without any issues. 3) **You don't want multiple updates to run at the same time** - Update and validate commands could use the same lockfile, used to prevent from running two times the functions at once - If the lockfile is more than 1h, then it should be removed and the update should run anyway. - Mods-update could also benefit from its lockfile. 4) **Move lockfiles checks to its own function** - Since we are now running multiple lockfiles, it would be wise to use a check script for that purpose, for example check_lockfile.sh, which would be run using check.sh for relevant commands. - We should not forget FastDL command which uses a lockfile as well. - All these lockfiles could use the jail method that we are already using, to remove the lockfiles in case of a script interruption by the user (kill or ctrl +c). That's all I can think about for now. If you have more ideas for lockfiles, please share.

kerem added the

type: feature

label

2026-02-27 02:57:21 +03:00

kerem commented

2026-02-27 02:57:21 +03:00

Author

Owner

@dgibbs64 commented on GitHub (Oct 27, 2018):

Happy with this suggestion and recommend it is implemented

@dgibbs64 commented on GitHub (Oct 27, 2018): Happy with this suggestion and recommend it is implemented

kerem commented

2026-02-27 02:57:21 +03:00

Author

Owner

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

number 1 has been implemented. A monitor delay now exists for all servers to prevent accidental reboot with monitor.

@dgibbs64 commented on GitHub (Nov 25, 2019): number 1 has been implemented. A monitor delay now exists for all servers to prevent accidental reboot with monitor.