starred/LinuxGSM

Fork 0

mirror of https://github.com/GameServerManagers/LinuxGSM.git synced 2026-04-24 21:56:01 +03:00

[GH-ISSUE #3244] New command gameserver log #2252

New issue

Open

opened 2026-02-27 03:01:45 +03:00 by kerem · 4 comments

kerem commented

2026-02-27 03:01:45 +03:00

Owner

Originally created by @AlexCloudDev on GitHub (Feb 13, 2021).
Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/3244

User Story

As a volunteer trying to help and improve the Docker container implementation, I want a new command like gameserver log to output the gameserver log into stdout like gameserver debug does.

Basic info

Distro: general
Game: general
Command: log
LinuxGSM version: [v20.1.3]

Further Information

I use a run.sh as entrypoint and therefore i need a proper PID 1 process for the container.
Due to the fact, that gameserver start spawns the server as new process, it can't be used.
Therefor it would be perfect, if some gameserver log command would exist, that outputs continuously the gameserver logs into stdout like gameserver debug does and runs as long as the gameserver.

Then, the run.sh called as entrypoint could look like this:
#!/bin/bash
....
su -c "gameserver start" $user
su -c "gameserver log" $user <------ running as long as the gameserver runs

With this approach, the docker logs command would flawlessly provide all the logging from the gameserver and the container would be stopped if the gameserver is.
And maybe a gameserver log command could provide handy information in other use cases than in a container environment.

Cheers

Originally created by @AlexCloudDev on GitHub (Feb 13, 2021). Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/3244 ## User Story As a volunteer trying to help and improve the Docker container implementation, I want a new command like **gameserver log** to output the gameserver log into stdout like **gameserver debug** does. ## Basic info * **Distro:** general * **Game:** general * **Command:** log * **LinuxGSM version:** [v20.1.3] ## Further Information I use a run.sh as entrypoint and therefore i need a proper PID 1 process for the container. Due to the fact, that _gameserver start_ spawns the server as new process, it can't be used. Therefor it would be perfect, if some **gameserver log** command would exist, that outputs continuously the gameserver logs into stdout like _gameserver debug_ does and runs as long as the gameserver. Then, the run.sh called as entrypoint could look like this: `#!/bin/bash` `....` `su -c "gameserver start" $user` `su -c "gameserver log" $user` <------ running as long as the gameserver runs With this approach, the _docker logs_ command would flawlessly provide all the logging from the gameserver and the container would be stopped if the gameserver is. And maybe a **gameserver log** command could provide handy information in other use cases than in a container environment. Cheers

kerem added the

type: feature

info: docker

labels

2026-02-27 03:01:45 +03:00

kerem commented

2026-02-27 03:01:46 +03:00

Author

Owner

@dgibbs64 commented on GitHub (Feb 13, 2021):

so my thought would be something as simple as tail -f on the console log

Alternatively, we could create a new command like ./gameserver debug something like ./gameserver start-docker that doesn't use tmux and outputs directly to the terminal

@dgibbs64 commented on GitHub (Feb 13, 2021): so my thought would be something as simple as `tail -f` on the console log Alternatively, we could create a new command like `./gameserver debug` something like `./gameserver start-docker` that doesn't use tmux and outputs directly to the terminal

kerem commented

2026-02-27 03:01:46 +03:00

Author

Owner

@AlexCloudDev commented on GitHub (Feb 18, 2021):

Hello,
yes, sounds good for me.
We just need a command that runs as long as the gameserver does and outputs log info.
I tried it with ./gameserver debug, but that doesn't fit well, it also requieres an input at the beginning (Y or N)
So something like ./gameserver start-docker would be superb

@AlexCloudDev commented on GitHub (Feb 18, 2021): Hello, yes, sounds good for me. We just need a command that runs as long as the gameserver does and outputs log info. I tried it with ./gameserver debug, but that doesn't fit well, it also requieres an input at the beginning (Y or N) So something like ./gameserver start-docker would be superb

kerem commented

2026-02-27 03:01:46 +03:00

Author

Owner

@dgibbs64 commented on GitHub (Feb 18, 2021):

Since there is a renewed interest in the docker container I will be spending some time on trying to get it to a production state that can be supported. I am going to need some support from docker experts :)

@dgibbs64 commented on GitHub (Feb 18, 2021): Since there is a renewed interest in the docker container I will be spending some time on trying to get it to a production state that can be supported. I am going to need some support from docker experts :)

kerem commented

2026-02-27 03:01:46 +03:00

Author

Owner

@AlexCloudDev commented on GitHub (Feb 19, 2021):

I'm far from being a docker expert, but i would like to help.
My approach so far is to let the user chose which gameserver he wants by setting a build argument at the docker-compose.yml.
Then, the image is build with this specific gameserver and at the end a run.sh script is called as entrypoint.
This script starts the gameserver and then calls tail --pid=pidof tmux -f /dev/null to keep the PID 1 alive as long as the gameserver runs, in absence of a proper command like ./gameserver log/start-docker etc.

For a public distribution of the images over hub.docker, we could use different tags for different games:
gameservermanagers/linuxgsm-docker:valheim
gameservermanagers/linuxgsm-docker:rust
etc

Another approach would be to build a uniform, unspecific image just with the linuxGSM script in the first place and install the gameserver files later via ENV at run.sh runtime.
I think, this question is a matter of personal flavor, but in the case, you're running multiple instances of the same game, you have to download the game files over and over again. Or if you destroy the container, you have also to re-download everything.

Also i made the whole dir where all files are downloaded a volume/host share, to give the gameserver's world/savegames and settings persistence.
I considered setting those server values like world name etc with ENVs, but due to the fact, that all the different games have own key words, i did not.

How can i help?

@AlexCloudDev commented on GitHub (Feb 19, 2021): I'm far from being a docker expert, but i would like to help. My approach so far is to let the user chose which gameserver he wants by setting a build argument at the docker-compose.yml. Then, the image is build with this specific gameserver and at the end a run.sh script is called as entrypoint. This script starts the gameserver and then calls _`tail --pid=`pidof tmux` -f /dev/null`_ to keep the PID 1 alive as long as the gameserver runs, in absence of a proper command like ./gameserver log/start-docker etc. For a public distribution of the images over hub.docker, we could use different tags for different games: gameservermanagers/linuxgsm-docker:valheim gameservermanagers/linuxgsm-docker:rust etc Another approach would be to build a uniform, unspecific image just with the linuxGSM script in the first place and install the gameserver files later via ENV at run.sh runtime. I think, this question is a matter of personal flavor, but in the case, you're running multiple instances of the same game, you have to download the game files over and over again. Or if you destroy the container, you have also to re-download everything. Also i made the whole dir where all files are downloaded a volume/host share, to give the gameserver's world/savegames and settings persistence. I considered setting those server values like world name etc with ENVs, but due to the fact, that all the different games have own key words, i did not. How can i help?

kerem referenced this issue

2026-02-27 03:54:55 +03:00

[PR #2253] [MERGED] Factorio update to other than stable/experimental releases #3551