question for linuxgsm/root user, and custom crontab

[Lxeon]

hello everyone,

i try to use custom crontab in linuxgsm user, and i find out it will restore to default if i restart container, and even before restart container, the crontab will not work as expected, like no run the command
here is the crontab

*/60 * * * * /app/mcserver update > /dev/null 2>&1
0 * * * * /app/mcserver send "kill @e[type=item]"

and then i try to set up crontab in root user like this

0 * * * * su - linuxgsm -c '/app/mcserver send "kill @e[type=item]"'

it can't run either.

when i run command alone, its show "server not running".

then i type

su - linuxgsm -c '/app/mcserver dt'

seems its wrong config file path. maybe its environment problem? but i check the 'env' in linuxgsm user and root user, its the same.

here is my docker-compose

  minecraft:
    image:  gameservermanagers/gameserver:mc
    container_name: minecraft
    volumes:
      - /mnt/ssd/docker/minecraft:/data
    network_mode: host
    restart: always

any idea for it ?

[irobot73]

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 the issue(s):

0 1 * * * /app/*server update-lgsm >> /data/log/crontab.log  # EVERY SUN @ 1:00
0 3 * * 1,3,5 /app/*server restart >> /data/log/crontab.log  # EVERY M,W,F @ 3:00
0 4 * * * /app/*server backup >> /data/log/crontab.log 2>&1  # EVERY DAY @ 4:00

Running these manually, via LINUXGSM/console (mostly) works (backup is still dorked), but via CRON, the path to the serverfiles doesn't rectify to '/data' but a subfolder of '/app':

�[K[ .... ] Stopping sdtdserver: 
�[K[�[31m FAIL �[0m] Stopping sdtdserver: Cannot access /app/serverfiles: No such directory

�[K[�[31m FAIL �[0m] Stopping sdtdserver: Cannot access /app/serverfiles: No such directory

�[K[ .... ] Backing up sdtdserver: 
�[K[�[31m FAIL �[0m] Backing up sdtdserver: Cannot access /app/serverfiles: No such directory

The update-lgsm seems to function as expected @ least

[Lxeon]

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 the issue(s):

0 1 * * * /app/*server update-lgsm >> /data/log/crontab.log  # EVERY SUN @ 1:00
0 3 * * 1,3,5 /app/*server restart >> /data/log/crontab.log  # EVERY M,W,F @ 3:00
0 4 * * * /app/*server backup >> /data/log/crontab.log 2>&1  # EVERY DAY @ 4:00

Running these manually, via LINUXGSM/console (mostly) works (backup is still dorked), but via CRON, the path to the serverfiles doesn't rectify to '/data' but a subfolder of '/app':

�[K[ .... ] Stopping sdtdserver: 
�[K[�[31m FAIL �[0m] Stopping sdtdserver: Cannot access /app/serverfiles: No such directory

�[K[�[31m FAIL �[0m] Stopping sdtdserver: Cannot access /app/serverfiles: No such directory

�[K[ .... ] Backing up sdtdserver: 
�[K[�[31m FAIL �[0m] Backing up sdtdserver: Cannot access /app/serverfiles: No such directory

The update-lgsm seems to function as expected @ least

yes, the root folder its wrong, i find backup problem have same question.

if i try to backup server with this command

docker exec -it -u linuxgsm minecraft bash
./mcserver backup

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.

[irobot73]

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.

'Odd' that the install & running of the server functions as expected (w/o the ENV variable), but these script(s)+ don't mirror the same shrug

[irobot73]

Tried to utilize the ENVIRONMENT over-ride. No love there either:

GameServerManagers/LinuxGSM#4387 (comment)

[compdude22]

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 /data/serverfiles at /app/serverfiles/, and change the symlink ownership so the checks would pass.

That said, I haven't been able to test if it will actually update the gameserver, as I need to wait for a new gameserver update.

ln -s /data/serverfiles /app
chown -h linuxgsm:linuxgsm /data/serverfiles

[irobot73]

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 /data/serverfiles at /app/serverfiles/, and change the symlink ownership so the checks would pass.

That said, I haven't been able to test if it will actually update the gameserver, as I need to wait for a new gameserver update.

ln -s /data/serverfiles /app
chown -h linuxgsm:linuxgsm /data/serverfiles

Hacky, which I try to shy away from....You'd need to do the same for the LOG folder as the RESTART will "re-create" a few paths as well (least it does RESTART this time shrug):

0 */12 * * * /app/*server restart >> /data/log/crontab.log # EVERY 12TH HOUR

Output:

�[K[ .... ] Stopping pwserver: 
�[K[ .... ] Stopping pwserver: Checking for log files
�[K[�[36m INFO �[0m] Stopping pwserver: Checking for log files: Creating log files
installing log dir: /app/log...�[32mOK�[0m
installing LinuxGSM log dir: /app/log/script...�[32mOK�[0m
creating LinuxGSM log: /app/log/script/pwserver-script.log...�[32mOK�[0m
installing console log dir: /app/log/console...�[32mOK�[0m
creating console log: /app/log/console/pwserver-console.log...�[32mOK�[0m
creating symlink to game log dir: /app/log/server -> /app/serverfiles/Pal/Saved/Logs...�[32mOK�[0m
creating symlink to steam log dir: /app/log/steam -> /data/.steam/steam/logs...�[32mOK�[0m

[dgibbs64]

Interesting as everything should point to /data

[irobot73]

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 to get you some decent logs for debugging (outside of the existing GIT 'bug' reports I've posted), I'll be glad to lend a hand

[compdude22]

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 models the same way that cron would invoke jobs:

sudo -u linuxgsm sh -c '/app/pwserver update'

This relies on the behavior documented in man sudo to not pass env-vars by default when running as a different user. I am running this in root, because that is how my Kubrenetes cluster starts the container.

If I had to guess, it looks like the LGSM_SERVERFILES evn var defined in the Dockerfile is not retained when cron calls the job. And this would make sense, although I'm not sure what the best way to fix this would be. Customarily, permanent env-vars could be placed in /etc/environment, but I don't know how viable that is here.

[irobot73]

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 models the same way that cron would invoke jobs:

sudo -u linuxgsm sh -c '/app/pwserver update'

This relies on the behavior documented in man sudo to not pass env-vars by default when running as a different user. I am running this in root, because that is how my Kubrenetes cluster starts the container.

If I had to guess, it looks like the LGSM_SERVERFILES evn var defined in the Dockerfile is not retained when cron calls the job. And this would make sense, although I'm not sure what the best way to fix this would be. Customarily, permanent env-vars could be placed in /etc/environment, but I don't know how viable that is here.

I had posted prior, having attempted a test re: LGSM_SERVERFILES...no love. Maybe something else I had missed (my Linux+ Fu being minimal...but learning)
GameServerManagers/LinuxGSM#4387 (comment)

Not too worried about the BACKUP, as I've rolled my own that does more (& better) than the LGSM built-in. It's the UPDATE & RESTART that still need hands-on (esp. w/ their symbolic links/re-mapping of folders to monitor/etc.)

[compdude22]

I had posted prior, having attempted a test re: LGSM_SERVERFILES...no love. Maybe something else I had missed (my Linux+ Fu being minimal...but learning)
GameServerManagers/LinuxGSM#4387 (comment)

I'm not as familiar with Docker Compose files as I am with Kubernetes manifests, but it seems as though the environment: variables only apply to the top-level entrypoint or command of the container, not necessarily to all of the subprocesses spawned from there. So in the case of docker-gameserver, cron is spawned off in entrypoint.sh but runs all cronjobs in a non-interactive, non-login /bin/sh shell, which does not load any of the normal initialization files, like ~/.profile or ~/.bashenv.

You might be able to try something like this, where the env-vars are always passed to all cronjobs in the container. The kicker is that you have to do this before the container's entrypoint.sh starts, so either the container image needs to be modified, or you author your own alternative entrypoint which runs first, then calls the normal entrypoint.sh.

# Append all the customary env-vars to the end of /etc/crontab
cat << EOF >> /etc/crontab
LGSM_GITHUBUSER=GameServerManagers
LGSM_GITHUBREPO=LinuxGSM
LGSM_GITHUBBRANCH=master
LGSM_LOGDIR=/data/log
LGSM_SERVERFILES=/data/serverfiles
LGSM_DATADIR=/data/data
LGSM_CONFIG=/data/config-lgsm
LGSM_DEV=false
EOF

[JensPenny]

I had the same issue. The solutions that @compdude22 explained work.
To just make this simple: I used following commands:

sudo cp /etc/environment /etc/environment.old
sudo env | sudo tee -a /etc/environment

This puts all environment variables in your /etc/environment file, where your cronjobs also have access to. Since all this runs containerized this feels like viable work-around.
The backup command does still back up the wrong directory. It backs up /app (where the app resides) instead of /data (where most of the time your server resides). This is solvable by mounting data inside /app probably, but I haven't tried that out yet.
As a sidenote, thanks for this thread. At least it helped solve my problem!

[irobot73]

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 to test:

ln -s /data/log /app && ln -s /data/serverfiles /app && ln -s /data/backup /app

Esp. as my CRON jobs seem to show these 'missing links' getting (re)created via LGSM reported here

I've also moved away from the LGSM Backup & rolled my own (scripts+ are further down that same link above). I can just grab what I need w/o the SteamCMD server files+ bloating the backup/SSD space

[dgibbs64]

Just an FYI I have now created a symlink from /app/serverfiles to /data/serverfiles this is mainly as a shortcut for users. I will add log as well. It should help with this issue. But ideally, I would like to get to the bottom of this issue of why cronjobs are ignoring the environment variables. Thanks for all your efforts on trying to work out the issue :)