David D.

Maybe a health check via Docker that we could then use the 'max_attempts' ala RESTART_POLICY (yeah, it's the server that's dorked...not the container)? ``` # https://docs.docker.com/compose/compose-file/compose-file-v3/#restart_policy restart_policy: condition: on-failure delay:...

Some (most?) of the scripts, for me, don't point to the 'serverfiles' if/when run via CRONTAB I redirected the jobs to a log file so I could see some of...

> > it will backup the /app/serverfiles, not the /data/serverfiles, even i using linuxgsm user before exec the container. > > I think it's all a matter of environment variables....

Tried to utilize the ENVIRONMENT over-ride. No love there either: https://github.com/GameServerManagers/LinuxGSM/issues/4387#issuecomment-1847860326

> I also faced the same wrong-directory issue when debugging why the container's default cronjob to update the gameserver was not working. My workaround was to create a symlink for...

> Interesting as everything _should_ point to /data Yes, *should*. Unfort, something in the logic is dorked in (most) any CRONTAB calls. If you have any process I can follow...

> Before I found this bug report, I had suspected an issue with environment variables and was able to use this invocation to isolate the `update` command, which I believe...

I'll have to start a fresh/vanilla container & try a few things out, TY. For the 2nd half, I think creating the required links will do the trick. Again, have...

Might try this docker-compose file: ``` services: linuxgsm-rust-bind: image: gameservermanagers/gameserver:rust container_name: HOA_RUSTs volumes: - ./:/data restart: unless-stopped ``` Aside from (some of) the scripts not running properly via CRONTAB, all...

It's not 100% obvious, but you can update the /data/config-lgsm/pzserver/_defautls.cfg ``` ## Predefined Parameters | https://docs.linuxgsm.com/configuration/start-parameters ip="0.0.0.0" adminpassword="CHANGE_ME" ``` Though, better to copy the relevant sections into the .../common.cfg instead...