container crashes when TYPE=AUTO_CURSEFORGE

[danielr1996]

Describe the problem

Starting a container with TYPE=AUTO_CURSEFORGE crashes with the error message unable to find jarfile, setting SETUP_ONLY shows SETUP_ONLY: java -Xmx4G -Xms4G -jar (note the missing argument after -jar). Am I missing something or is this a bug?

After digging around a bit I think the problem is within mc-image-helper itself. If I understand correctly mc-image-helper install-curseforge "${args[@]}" should populate /data/.install-curseforge.env with the SERVER and TYPE variables, but the content is (

MODPACK_NAME="All the Mods 10"
MODPACK_VERSION="0.12"
... (these two lines are repeated like 50 times)

Unfortunately I currently cannot use docker on my mac because it crashes all the time after the last update so my ability to manually edit files in the container is limited, also repeatedly deleting all data and redownload it from curseforge quickly exhausts the rate limits, is there a known workaround for this, it would make debugging easier because I could always start from a clean state?

Container definition

apiVersion: v1
kind: Pod
metadata:
  name: atm-minecraft-0
spec:
  containers:
    - name: atm-minecraft
      image: itzg/minecraft-server:2024.6.1-java21-graalvm
      env:
        - name: EULA
          value: 'TRUE'
        - name: TYPE
          value: AUTO_CURSEFORGE
        - name: VERSION
          value: '1.21'
        - name: DIFFICULTY
          value: easy
        - name: MAX_PLAYERS
          value: '20'
        - name: MAX_WORLD_SIZE
          value: '10000'
        - name: MAX_BUILD_HEIGHT
          value: '256'
        - name: MAX_TICK_TIME
          value: '60000'
        - name: SPAWN_PROTECTION
          value: '16'
        - name: VIEW_DISTANCE
          value: '20'
        - name: MODE
          value: survival
        - name: MOTD
          value: Welcome to Minecraft on Kubernetes!
        - name: LEVEL_TYPE
          value: DEFAULT
        - name: LEVEL
          value: world
        - name: MODRINTH_ALLOWED_VERSION_TYPE
          value: release
        - name: MEMORY
          value: 4G
        - name: OVERRIDE_SERVER_PROPERTIES
          value: 'true'
        - name: CF_API_KEY
          valueFrom:
            secretKeyRef:
              name: cf-api-key
              key: cf-api-key
        - name: CF_SLUG
          value: all-the-mods-10
        - name: CF_PARALLEL_DOWNLOADS
          value: '4'
        - name: SETUP_ONLY
          value: 'true'

Container logs

[init] Running as uid=1000 gid=3000 with /data as 'drwxrwsr-x 9 0 2000 4096 Jul 14 17:14 /data'
[mc-image-helper] 17:14:19.445 INFO  : Requested CurseForge modpack All the Mods 10-0.12 is already installed for All the Mods 10 - ATM10
[init] Setting mode
[init] Setting initial memory to 4G and max to 4G
[init] Starting the Minecraft server...
SETUP_ONLY: java -Xmx4G -Xms4G -jar

[itzg]

You can debug the pod's content like any other container, change the entrypoint/command to something like the following

          command:
            - bash
            - -c
            - "sleep 999999"

and then you can exec a new shell inside the pod while the entrypoint is sleeping.

[itzg]

BTW, the .install-curseforge.env should contain the following:

SERVER="/data/./run.sh"
FAMILY="FORGE"
VERSION="1.21"
TYPE="NEOFORGE"
MODPACK_NAME="All the Mods 10"
MODPACK_VERSION="0.12"

As such, my setup line looks like:

mc-1  | [init] Using Forge supplied run.sh script...
mc-1  | SETUP_ONLY: bash /data/./run.sh

I'll cut a new fixed released tag since it looks like I haven't done that in a little while.

[itzg]

also repeatedly deleting all data and redownload it from curseforge quickly exhausts the rate limits

I don't see a persistent volume attached to /data. That would explain why data is getting "deleted" repeatedly. Under normal circumstances the CurseForge effectively caches the resulting jar files since they're already downloaded.

[itzg]

New image release is itzg/minecraft-server:2024.7.0-java21-graalvm

[danielr1996]

also repeatedly deleting all data and redownload it from curseforge quickly exhausts the rate limits

I don't see a persistent volume attached to /data. That would explain why data is getting "deleted" repeatedly. Under normal circumstances the CurseForge effectively caches the resulting jar files since they're already downloaded.

I ommitted the volume and volumeMounts for brevity, but the caching does indeed work.

Anyways, updating the image works, thank you very much for the fast fix.