Skip to content

question for linuxgsm/root user, and custom crontab #39

Open
Open
question for linuxgsm/root user, and custom crontab#39

Description

@Lxeon
Lxeon
opened on Nov 25, 2023

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 ?

Activity

  1. irobot73 commented on Dec 8, 2023

    @irobot73
    irobot73
    on Dec 8, 2023

    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

  2. Lxeon commented on Dec 8, 2023

    @Lxeon
    Lxeon
    on Dec 8, 2023
    Author

    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.

  3. irobot73 commented on Dec 8, 2023

    @irobot73
    irobot73
    on Dec 8, 2023

    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

  4. irobot73 commented on Dec 8, 2023

    @irobot73
    irobot73
    on Dec 8, 2023

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

    GameServerManagers/LinuxGSM#4387 (comment)

  5. compdude22 commented on Feb 11, 2024

    @compdude22
    compdude22
    on Feb 11, 2024

    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

  6. irobot73 commented on Feb 11, 2024

    @irobot73
    irobot73
    on Feb 11, 2024

    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

  7. dgibbs64 commented on Feb 11, 2024

    @dgibbs64
    dgibbs64
    on Feb 11, 2024
    Member

    Interesting as everything should point to /data

  8. irobot73 commented on Feb 11, 2024

    @irobot73
    irobot73
    on Feb 11, 2024

    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

  9. compdude22 commented on Feb 11, 2024

    @compdude22
    compdude22
    on Feb 11, 2024

    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.

  10. irobot73 commented on Feb 12, 2024

    @irobot73
    irobot73
    on Feb 12, 2024

    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.)

  11. compdude22 commented on Feb 12, 2024

    @compdude22
    compdude22
    on Feb 12, 2024

    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

  12. JensPenny commented on Feb 16, 2024

    @JensPenny
    JensPenny
    on Feb 16, 2024

    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!

  13. irobot73 commented on Feb 16, 2024

    @irobot73
    irobot73
    on Feb 16, 2024

    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

  14. dgibbs64 commented on Feb 17, 2024

    @dgibbs64
    dgibbs64
    on Feb 17, 2024
    Member

    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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions