Feature Requests

[mrk3767]

Creating a list of things on the top of my mind. Feel free to break these out into individual issues. I may try to resolve some of these myself over the next week or so, but I have to jump to another project tomorrow so it might be a bit.

2023.11.02

• [x] #19
• [x] #11
• [x] Handle process termination more gracefully
• [x] Start the server on container start
• [ ] Send all relevant logs to stdout / stderr
• [ ] Break out mount points to separate save data from game data

[azixus]

Great, thanks for the list! Will definitely try to implement these.

[mrk3767]

Make rcon use an env variable for username and password instead of passing on command line

The command line options have --env which could just pull from what's already set

--env value, -e value Config environment with server credentials (default: "default")

Reduce size of image

Maybe some of the libraries aren't necessary or could be cleaned up. Can we just copy in exactly what we need to get the game functioning?

Handle process termination more gracefully

Right now, the game is kicked off as a child process which won't receive termination signals. Could a process manager or signal traps be used to enable response and graceful shutdown?

Ideally, when the container receives a shutdown signal, the following should happen:

1. Message is sent to any players on the server noting that it will shut down in 30 seconds
2. RCON signal sent to the server to shut down
3. Check for shutdown OR if 60s have passed
4. Force shutdown

Send all relevant logs to stdout / stderr

When debugging, it would be nice to have all logs on the follow and be able to filter them on where they are coming from.

[NIREKI]

@azixus I think for starting the server on container startup you could just merge the entrypoint.sh and the startup.sh scripts and provide them as a real entrypoint (not through cmd) to the Dockerfile. That way the server would also get updated every time the container starts and the files would get verified, which in my view isn't a bad thing.

[azixus]

@NIREKI This sounds reasonable, will update that during the weekend.

Regarding the size of the image, there's a storage / starting time tradeoff. We can save 6.4GB by removing the pdb file + Content/Movies (thanks WC...), but it'll have to be re-downloaded each time in the entrypoint, and maybe in startup (I can probably add a --no-update flag to prevent that). I think it's still worth removing the files, let me know if you agree / have other ideas.

[NIREKI]

@azixus If you want to, I could also do a PR regarding the startup change.

Deleting the pdb file and some content seems like a good idea to save some space but with that change updating the server could be a problem because all the files will be downloaded again. Also if the update is actually part of the startup script (as i supposed) that would happen at every server startup and thus make no sense at all and only cause unnecessary traffic which in my opinion is more important than saving space.

I don't know, that's just a decision you have to make.

[azixus]

Please do :). You can likely add a call to manager start and we can update the documentation.

[NIREKI]

@azixus okay, i'm on it. I'm going to merge the entrypoint.sh and the start.sh Script, add some more volumes and call the start.sh or the Manager start on container Startup.

[NIREKI]

Break out mount points to separate save data from game data

Maybe it would also make sense to seperate save data from game data and create an extra volume for server config files?

Make rcon use an env variable for username and password instead of passing on command line

Those two could be added pretty easily. @azixus Should i try to add those to #6 or would you prefer a new PR and branch for those?

[acollien]

Doe the sever 'pause' when the last player disconnects? If not, is that a variable possibility?

[NIREKI]

Doe the sever 'pause' when the last player disconnects? If not, is that a variable possibility?

@acollien that's actually not supported by the ARK server, nor was it in ARK SE.

[acollien]

acollien that's actually not supported by the ARK server, nor was it in ARK SE. @NIREKI Wishful thinking for ASA!

[mrk3767]

Shutting down the server does effectively pause it. I have a script setup to check the player count and shut down the server automatically if there are 0 players for 15m. My community has the ability to turn it back on via a slash command on discord. It's been running since Thursday without any issues. It's been turned off and on plenty of times. I had a similar setup for ASE that ran like that for years.

[acollien]

@mrk3767 Shutting down the server does effectively pause it...

Yeah nice, that could work. Any chance you have some documentation you can link me, please?

[loginator]

@azixus I also created a c# tool for editing the config using environment variables. So there would be only one place to make changes you can take a look into it here if you want to: IniGenerator. If you want me to I can create a PR adding it to your docker container and tooling. It comes with the disadvantage of removing comments from the ini files if there were any before.

[azixus]

@azixus I also created a c# tool for editing the config using environment variables. So there would be only one place to make changes you can take a look into it here if you want to: IniGenerator. If you want me to I can create a PR adding it to your docker container and tooling. It comes with the disadvantage of removing comments from the ini files if there were any before.

This looks like a cool feature and I like the strategy, I'd definitely want to include it in the future! However, I'm a bit reluctant to add .NET dependencies to the project; we will be moving to a Python-based manager in the future. Hopefully, we'll be able to offer a similar feature with TOML-based (for instance) configuration files.

For now, if you'd like to make a contribution to the repo, I'll gladly take a PR on the dev branch explaining the Proxmox fix when switching the CPU type to "host" mode.

[loginator]

@azixus I also created a c# tool for editing the config using environment variables. So there would be only one place to make changes you can take a look into it here if you want to: IniGenerator. If you want me to I can create a PR adding it to your docker container and tooling. It comes with the disadvantage of removing comments from the ini files if there were any before.

This looks like a cool feature and I like the strategy, I'd definitely want to include it in the future! However, I'm a bit reluctant to add .NET dependencies to the project; we will be moving to a Python-based manager in the future. Hopefully, we'll be able to offer a similar feature with TOML-based (for instance) configuration files.

For now, if you'd like to make a contribution to the repo, I'll gladly take a PR on the dev branch explaining the Proxmox fix when switching the CPU type to "host" mode.

Sure thing added a PR for that. Got your point with the extra dependency. Maybe I can help later on when you guys switched to Python it's just that I'm not really experienced with bash scripting.

[mycarrysun]

Howdy folks - I just threw up a PR to make it so the manager file can be ran from anywhere instead of being required to run it from the directory of the repo.

I was also going to add a new command to it to retrieve the logs of the docker containers, thoughts?

[azixus]

Howdy folks - I just threw up a PR to make it so the manager file can be ran from anywhere instead of being required to run it from the directory of the repo.

I was also going to add a new command to it to retrieve the logs of the docker containers, thoughts?

I think it makes sense since the manager is already used to hide the docker shenanigans. We could specialize ./manager.sh logs to display the container logs and the rest of the commands are forwarded as usual.

[mycarrysun]

I think it makes sense since the manager is already used to hide the docker shenanigans. We could specialize ./manager.sh logs to display the container logs and the rest of the commands are forwarded as usual.

Yup that's exactly what I was thinking, it wouldn't be super clean to get the logs from the container. I will put up a PR.

Are there any other log files that aren't going to be output by docker compose logs? When I was debugging my own server seemed like there was extra stuff in one of the numbered logs in ark_data/ShooterGame/Saved/Logs/ShooterGame_3.log for example, but maybe those are also in the docker logs (I don't remember being able to see them with that command though, which is why I kept checking those files).

[azixus]

Are there any other log files that aren't going to be output by docker compose logs? When I was debugging my own server seemed like there was extra stuff in one of the numbered logs in ark_data/ShooterGame/Saved/Logs/ShooterGame_3.log for example, but maybe those are also in the docker logs (I don't remember being able to see them with that command though, which is why I kept checking those files).

IIRC the ShooterGame_N.log are generated when multiple servers are ran in parallel from the same directory. docker compose logs currently only shows the content of ShooterGame.log. I don't think we need to log anything else at the moment, correct me if I'm mistaken.

[mycarrysun]

IIRC the ShooterGame_N.log are generated when multiple servers are ran in parallel from the same directory. docker compose logs currently only shows the content of ShooterGame.log. I don't think we need to log anything else at the moment, correct me if I'm mistaken.

Interesting, I'm thinking this may be a symptom of a bug then, as I was getting this behavior just from running a single instance. I was using the manager.sh start/restart commands to handle updates to the .env/.ini files and when I had invalid config I think that's when I experienced the behavior of seeing ShooterGame_N.logs. It may just be exceptional behavior though that you wouldn't care about handling (since I had invalid config values), not sure.

[mycarrysun]

Digging into this more today - I noticed a ShooterGame_2.log showed up when I ran a restart command through the manager.sh. It eventually errored out with:

~/code/ark-server-docker$ cat ark_data/ShooterGame/Saved/Logs/ShooterGame_2.log
[2023.12.17-20.52.44:895][  0]Log file open, 12/17/23 20:52:44
[2023.12.17-20.52.44:895][  0]LogMemory: Platform Memory Stats for WindowsServer
[2023.12.17-20.52.44:896][  0]LogMemory: Process Physical Memory: 330.10 MB used, 334.89 MB peak
[2023.12.17-20.52.44:896][  0]LogMemory: Process Virtual Memory: 303.58 MB used, 303.58 MB peak
[2023.12.17-20.52.44:896][  0]LogMemory: Physical Memory: 11928.62 MB used,  20196.45 MB free, 32125.07 MB total
[2023.12.17-20.52.44:896][  0]LogMemory: Virtual Memory: 11928.62 MB used,  28388.45 MB free, 40317.07 MB total
[2023.12.17-20.52.45:817][  0]ARK Version: 32.28
[2023.12.17-20.52.46:914][  0]Primal Game Data Took 0.78 seconds
[2023.12.17-20.52.47:525][  0]ERROR!!! FAtlasSaveManager::LoadOperationSql: SQL database is corrupt and the save game is compromised! Exiting...

I seem to have to take the docker container down and up again for this to not happen. I use docker compose down && docker compose up -d for this.