starred/LinuxGSM

Fork 0

mirror of https://github.com/GameServerManagers/LinuxGSM.git synced 2026-04-25 06:05:57 +03:00

[GH-ISSUE #1943] Improve instances management using linuxgsm.sh #1529

New issue

Open

opened 2026-02-27 02:57:38 +03:00 by kerem · 7 comments

kerem commented

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

Owner

Originally created by @fs86 on GitHub (Jul 20, 2018).
Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/1943

I have a DST server (Master and Caves) which are connected to each other. Both instances run under the same user. When an update is applied with "./dstserver-1 update", dstserver-1 will be restarted when the update process has finished. Unfortunately the second instance "dstserver-2" (which is my Caves server) doesn't get restarted and runs on an old server version. Is there already a possibility to force each server instance to restart after an updated has been applied?

Originally created by @fs86 on GitHub (Jul 20, 2018). Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/1943 I have a DST server (Master and Caves) which are connected to each other. Both instances run under the same user. When an update is applied with "./dstserver-1 update", dstserver-1 will be restarted when the update process has finished. Unfortunately the second instance "dstserver-2" (which is my Caves server) doesn't get restarted and runs on an old server version. Is there already a possibility to force each server instance to restart after an updated has been applied?

kerem added the

type: feature

game: Don't Starve Together

labels

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

kerem commented

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

Author

Owner

@UltimateByte commented on GitHub (Jul 20, 2018):

This would likely require a massive overhaul of LinuxGSM and the way it manages instances to be accomplished directly. But the workaround is easy:
Use force-update on the first server, and stop on the second, then about one or two minutes later (you know the time it takes to update better than me), start the second server. You can do all that using cronjobs.
https://github.com/GameServerManagers/LinuxGSM/wiki/Cronjobs

GitHub
GameServerManagers/LinuxGSM
LinuxGSM - Linux Game Server Managers_

@UltimateByte commented on GitHub (Jul 20, 2018): This would likely require a massive overhaul of LinuxGSM and the way it manages instances to be accomplished directly. But the workaround is easy: Use force-update on the first server, and stop on the second, then about one or two minutes later (you know the time it takes to update better than me), start the second server. You can do all that using cronjobs. https://github.com/GameServerManagers/LinuxGSM/wiki/Cronjobs <blockquote><img src="https://avatars2.githubusercontent.com/u/20358373?s=400&v=4" width="48" align="right"><div><img src="https://assets-cdn.github.com/favicon.ico" height="14"> GitHub</div><div><strong><a href="https://github.com/GameServerManagers/LinuxGSM">GameServerManagers/LinuxGSM</a></strong></div><div>LinuxGSM - Linux Game Server Managers_</div></blockquote>

kerem commented

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

Author

Owner

@fs86 commented on GitHub (Jul 20, 2018):

Yes, that should work, but it would result in a server restart even when there is no new update. And I want to prevent a server disconnect when it is not necessary.

@fs86 commented on GitHub (Jul 20, 2018): Yes, that should work, but it would result in a server restart even when there is no new update. And I want to prevent a server disconnect when it is not necessary.

kerem commented

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

Author

Owner

@UltimateByte commented on GitHub (Jul 22, 2018):

In fact, what you're proposing would benefit everyone with multiple instances under the same install.
We could add a parameter to stop and restart all instances upon update.
The question is: How will it detect other instances.
Maybe we could make a separate script for that, like "linuxgsm-instancesmanage.sh" or something like that.

@UltimateByte commented on GitHub (Jul 22, 2018): In fact, what you're proposing would benefit everyone with multiple instances under the same install. We could add a parameter to stop and restart all instances upon update. The question is: How will it detect other instances. Maybe we could make a separate script for that, like "linuxgsm-instancesmanage.sh" or something like that.

kerem commented

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

Author

Owner

@fs86 commented on GitHub (Jul 23, 2018):

What about adding a configuration file with a grouped list of instances? If "./gameserver-1 update" is executed, the script can look for other gameserver instances within the same group as "gameserver-1" and perform a restart.

@fs86 commented on GitHub (Jul 23, 2018): What about adding a configuration file with a grouped list of instances? If "./gameserver-1 update" is executed, the script can look for other gameserver instances within the same group as "gameserver-1" and perform a restart.

kerem commented

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

Author

Owner

@UltimateByte commented on GitHub (Jul 23, 2018):

That's a design choice to make.

I suggest a dedicated script like linuxgsm-instances.sh which would be able to detect instances, then manage them from one script. There would be a master instance (for updates), then slaves. It would loop through bash scripts in rootdir and ask to validate a list. You could input commands like linuxgsm-instances.sh start instancename or linuxgsm-instances.sh restart all, and it would be smart enough so that if you run update or validate it knows it needs to run it only on the main instance and shutdown the others when an update is found or upon validating.

What do you think?

@dgibbs64 Would you do it, and if yes, would you validate my idea?

@UltimateByte commented on GitHub (Jul 23, 2018): That's a design choice to make. I suggest a dedicated script like `linuxgsm-instances.sh` which would be able to detect instances, then manage them from one script. There would be a master instance (for updates), then slaves. It would loop through bash scripts in rootdir and ask to validate a list. You could input commands like `linuxgsm-instances.sh start instancename` or `linuxgsm-instances.sh restart all`, and it would be smart enough so that if you run `update` or `validate` it knows it needs to run it only on the main instance and shutdown the others when an update is found or upon validating. What do you think? @dgibbs64 Would you do it, and if yes, would you validate my idea?

kerem commented

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

Author

Owner

@dgibbs64 commented on GitHub (Jul 23, 2018):

@UltimateByte I think its something we have talked about before using ./linuxgsm.sh to manage it. Sounds like a great idea and it should be relatively easy for the instances script to identify instances within its own dir. Would be a great way to practice using milestones as well :)

@dgibbs64 commented on GitHub (Jul 23, 2018): @UltimateByte I think its something we have talked about before using `./linuxgsm.sh` to manage it. Sounds like a great idea and it should be relatively easy for the instances script to identify instances within its own dir. Would be a great way to practice using milestones as well :)

kerem commented

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

Author

Owner

@UltimateByte commented on GitHub (Jul 23, 2018):

Oh yeah, managing directly within linuxgsm.sh would be the greatest for sure, forgot about that idea.
Let's talk about milestones on Discord! :D

@UltimateByte commented on GitHub (Jul 23, 2018): Oh yeah, managing directly within linuxgsm.sh would be the greatest for sure, forgot about that idea. Let's talk about milestones on Discord! :D