Docker container not starting due to... different jar?

[Jakllp]

The container was working fine but at some point it stopped starting up properly.

MC: Paper 1.16.5
Running: java8-multiarch (other multiarch-images won't start on my Pi4 which is strange)

I took a peek into the data folder as I have that mounted to a folder on the host-system.
There were 2 .jars in there:
paper-1.16.5-571.jar
paper_server-1.16.5-latest.jar

It has been using the latter one before but is now always downloading paper-1.16.5-571.jar - which doesn't start as it is seemingly looking for paper_server-1.16.5-latest.jar
(my best guess)

[itzg]

Can you set the environment variable DEBUG to "true" and provide the output from that?

[Jakllp]

The Output (for some reason the code thing isn't working...):
[init] Running as uid=1000 gid=1000 with /data as 'drwxrwxr-x 10 1000 1000 4096 Mar 28 19:22 /data'
[init] Resolved version given LATEST into 1.16.5
[init] Resolving type given PAPER
+[[ -n '' ]]
++ curl -fsSL https://papermc.io/api/v2/projects/paper/versions/1.16.5 -H 'accept: application/json'
++ jq '.builds[-1]'
+build=571
+case $? in
+'[' 0 '!=' 0 ']'
++ curl -fsSL https://papermc.io/api/v2/projects/paper/versions/1.16.5/builds/571 -H 'accept: application/json'
++ jq -r .downloads.application.name
+export SERVER=paper-1.16.5-571.jar
+SERVER=paper-1.16.5-571.jar
+'[' 0 '!=' 0 ']'
+'[' -f paper-1.16.5-571.jar ']'
+zarg=(-z "$SERVER")
+log 'Removing old PaperMC versions ...'
+echo '[init] Removing old PaperMC versions ...'
[init] Removing old PaperMC versions ...
+for f in paper-*.jar
+[[ paper-1.16.5-571.jar != paper-1.16.5-571.jar ]]
+log 'Downloading PaperMC 1.16.5 (build 571) ...'
+echo '[init] Downloading PaperMC 1.16.5 (build 571) ...'
[init] Downloading PaperMC 1.16.5 (build 571) ...
+curl -fsSL -o paper-1.16.5-571.jar -z paper-1.16.5-571.jar https://papermc.io/api/v2/projects/paper/versions/1.16.5/builds/571/downloads/paper-1.16.5-571.jar -H 'accept: application/java-archive'
+'[' 0 '!=' 0 ']'
+export TYPE=SPIGOT
+TYPE=SPIGOT
+export SKIP_LOG4J_CONFIG=true
+SKIP_LOG4J_CONFIG=true
+exec /start-finalSetupWorld
+: world
+export LEVEL
+'[' SPIGOT = FEED-THE-BEAST ']'
+worldDest=/data/world
+[[ -n '' ]]
+exec /start-finalSetupModpack
+CURSE_URL_BASE=https://minecraft.curseforge.com/projects
+isTrue
+local value=
+result=
+case ${value} in
+result=1
+return 1
+[[ -n '' ]]
+[[ -n '' ]]
+[[ -n '' ]]
+[[ -n '' ]]
+exec /start-finalSetupModconfig
+'[' -d /plugins ']'
+'[' -d /mods ']'
+: /data/config
+'[' -d /config ']'
+exec /start-finalSetupServerProperties

I like the line
+ [[ paper-1.16.5-571.jar != paper-1.16.5-571.jar ]]

[Jakllp]

Wait no I'm stupid - didn't read the log properly.
I defined 1.5G as MEMORY
and it says:
Invalid initial heap size: -Xms1.5G

(even though I'm fairly certain that it ran with that statement before but yeah...)

I ran multiarch and multiarch-latest with DEBUG=TRUE and got this:

[init] Running as uid=1000 gid=1000 with /data as 'drwxrwxr-x 10 1000 1000 4096 Mar 28 2021 /data'
curl: (28) Timeout was reached

[itzg]

Wait no I'm stupid - didn't read the log properly.
I defined 1.5G as MEMORY
and it says:
Invalid initial heap size: -Xms1.5G

(even though I'm fairly certain that it ran with that statement before but yeah...)

I switched multiarch to Java 11 recently and it could be that they got stricter about integer memory settings.

I ran multiarch and multiarch-latest with DEBUG=TRUE and got this:

[init] Running as uid=1000 gid=1000 with /data as 'drwxrwxr-x 10 1000 1000 4096 Mar 28 2021 /data'
curl: (28) Timeout was reached

So, you "fixed" the original problem, but now it is failing to startup with this? A curl timeout could be hopefully a temporary networking issue on your or their end.

[Jakllp]

Oh sorry for the confusion:

I was using java8-multiarch - that didn't like 1.5G

The curl timeout happens with both multiarch and multiarch-latest which both have never been working for me.
I tried that on different Raspberry Pis - 32bit and 64bit and the behaviour was pretty weird.
If you want I can do some more testing with 32 vs 64bit ARM
So that's technically a different issue.

[itzg]

The curl timeout happens with both multiarch and multiarch-latest which both have never been working for me.
I tried that on different Raspberry Pis - 32bit and 64bit and the behaviour was pretty weird.

Ah, that's a known issue with a fix on the host side

#755 (comment)

[Jakllp]

Is that actually the same issue?

My log ends after the curl timeout
And I tried the :Z flag - I still got the curl timeout

Or am I missing something here?
It's pretty late rn so... That's a possibility

[itzg]

I think so. The ":Z" approach only seemed to work for one person. The specific comment that seemed to help most people was installing libseccomp.

[Jakllp]

Ah okay!

Yeah I got a bit confused as the newest version apt-get served me wasn't the newest version but using the link someone provided in that issue worked.

Thank you!
(Isn't it funny how some random little package can have such a big impact)