Downloading minecraft_server..jar error Timeout

[vonloschz]

Hello,
I got this error from the 2021.3.0-multiarch-latest image.

is it really minecraft_server**..**jar and not minecraft_server.jar ?

2021-02-07T20:06:34.629289451Z [init] Running as uid=1000 gid=1000 with /data as 'drwxrwxr-x 2 1000 1000 4096 Feb 7 2021 /data',
2021-02-07T20:06:35.699395484Z curl: (28) Timeout was reached,
2021-02-07T20:06:35.708349968Z [init] Resolved version given LATEST into ,
2021-02-07T20:06:35.708894314Z [init] Resolving type given VANILLA,
2021-02-07T20:06:35.723557000Z [init] Downloading minecraft_server..jar ...,
2021-02-07T20:06:36.776268801Z curl: (28) Timeout was reached,
2021-02-07T20:06:36.785001565Z [init] ERROR failed to obtain version manifest URL (28),

[vonloschz]

running under Raspberry Pi 4 2G.

[itzg]

I can't really help with networking issues, but yeah, there seems to be a bug where it continued on even when the version lookup failed.

[itzg]

I have now pushed better handling of the version lookup failure.

[vonloschz]

other docker containers on this Raspberry doesn't have networking issues.
Why minecraft_server..jar have 2 . ?

[mrowek]

same here
vanilla and forge cant fetch url

minecraft         | curl: (28) Timeout was reached
minecraft exited with code 28

getting this just after starting container

using docker-compose
(already has 6 other containers running fine)

[vonloschz]

same error message with 2021.4.0-multiarch-latest

[itzg]

Can you try a couple of things:

• see if an older tag 2021.1.0-multiarch-latest goes back to working
• provide the output of docker run --rm --entrypoint curl itzg/minecraft-server:2021.4.0-multiarch-latest -v -fsSL -o /dev/null https://launchermeta.mojang.com/mc/game/version_manifest.json

[vonloschz]

pi@pi4ng:~ $ docker run --rm --entrypoint curl itzg/minecraft-server:2021.4.0-multiarch-latest -v -fsSL -o /dev/null https://launchermeta.mojang.com/mc/game/version_manifest.json

• Closing connection 0
  curl: (28) Timeout was reached

[vonloschz]

pi@pi4ng:~ $ docker run -e EULA=TRUE -d -p 25565:25565 --name mc_2021.1.0 itzg/minecraft-server:2021.1.0-multiarch-latest
ac7737f15840c44a8997ff7f6f195516c75946c9801427b0853822a4d79caaaf

[init] Running as uid=1000 gid=1000 with /data as 'drwxrwxr-x 2 1000 1000 4096 Jan 9 2021 /data',
curl: (28) Timeout was reached,
[init] Resolved version given LATEST into ,
[init] Resolving type given VANILLA,
[init] Downloading minecraft_server..jar ...,
curl: (28) Timeout was reached,
[init] ERROR failed to obtain version manifest URL (28),

[itzg]

Thanks for the quick info. And let's narrow it down by doing one more at 2021.3.0-multiarch-latest

[vonloschz]

pi@pi4ng:~ $ docker run --rm --entrypoint curl itzg/minecraft-server:2021.3.0-multiarch-latest -v -fsSL -o /dev/null https://launchermeta.mojang.com/mc/game/version_manifest.json

• Closing connection 0
  curl: (28) Timeout was reached

[vonloschz]

pi@pi4ng:~ $ docker run -e EULA=TRUE -d -p 25565:25565 --name mc_2021.3.0 itzg/minecraft-server:2021.3.0-multiarch-latest
44fa1f25c3062fd1d142de440a381dad228045a1d1e1dd6fa71bcbbbde85a337

[init] Running as uid=1000 gid=1000 with /data as 'drwxrwxr-x 2 1000 1000 4096 Feb 7 2021 /data',
curl: (28) Timeout was reached,
[init] Resolved version given LATEST into ,
[init] Resolving type given VANILLA,
[init] Downloading minecraft_server..jar ...,
curl: (28) Timeout was reached,
[init] ERROR failed to obtain version manifest URL (28),

[itzg]

pi@pi4ng:~ $ docker run -e EULA=TRUE -d -p 25565:25565 --name mc_2021.1.0 itzg/minecraft-server:2021.1.0-multiarch-latest
ac7737f15840c44a8997ff7f6f195516c75946c9801427b0853822a4d79caaaf

[init] Running as uid=1000 gid=1000 with /data as 'drwxrwxr-x 2 1000 1000 4096 Jan 9 2021 /data',
curl: (28) Timeout was reached,
[init] Resolved version given LATEST into ,
[init] Resolving type given VANILLA,
[init] Downloading minecraft_server..jar ...,
curl: (28) Timeout was reached,
[init] ERROR failed to obtain version manifest URL (28),

Oh, I misread the earlier comment. So even 2021.1.0 is failing for you?

I know you have other containers running fine, but it really seems to be a networking issue beyond the control of the image. The curl command I am having you run is straight from the base image adoptopenjdk:latest with an apt install. Maybe it's a DNS issue and other containers on your system aren't needing to reach out to public URLs.

[vonloschz]

From the same docker env as the others tests ....

docker pull debian
docker run -it debian

root@a9e15cbb0401:/# ping -c3 9.9.9.9
PING 9.9.9.9 (9.9.9.9) 56(84) bytes of data.
64 bytes from 9.9.9.9: icmp_seq=1 ttl=58 time=25.0 ms
64 bytes from 9.9.9.9: icmp_seq=2 ttl=58 time=25.7 ms
64 bytes from 9.9.9.9: icmp_seq=3 ttl=58 time=26.4 ms

--- 9.9.9.9 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 25.018/25.689/26.360/0.547 ms

root@a9e15cbb0401:/# apt update ... ok
root@a9e15cbb0401:/# apt install dnsutils ... ok

root@a9e15cbb0401:/# dig +short launchermeta.mojang.com
d1dulol58c5ch1.cloudfront.net.
13.224.35.130

[itzg]

Instead of debian can you use the base image adoptopenjdk:latest for experiments. It in turn is based on Debian, but want to keep the experiments consistent.

Sorry, I only threw out DNS as a possible cause because I am running out of ideas. I would recommend you experiment with adoptopenjdk:latest, apt install curl, and re-try the versions retrieval call.

[itzg]

...BTW, dig and curl do not necessarily use the same mechanisms for DNS resolution:

https://serverfault.com/questions/866183/understanding-the-difference-between-dns-resolvers

Again, I'm not trying to imply your scenario is only a DNS issue.

[vonloschz]

my host

pi@pi4ng:~ $ grep hosts /etc/nsswitch.conf
hosts: files mdns4_minimal [NOTFOUND=return] dns

pi@pi4ng:~ $ curl -v -fsSL -o /dev/null https://launchermeta.mojang.com/mc/game/version_manifest.json
...
{ [15914 bytes data]

• Connection #0 to host launchermeta.mojang.com left intact

my debian test

docker run -it debian
root@86779a16661a:/# apt update && apt install curl -fy

root@88042e3f16a2:/# grep hosts /etc/nsswitch.conf
hosts: files dns

root@88042e3f16a2:/# curl -v -fsSL -o /dev/null https://launchermeta.mojang.com/mc/game/version_manifest.json
...
{ [15914 bytes data]

• Connection #0 to host launchermeta.mojang.com left intact

container - minecraft-server:2021.4.0-multiarch-lates

pi@pi4ng:~ $ docker run --rm --entrypoint curl itzg/minecraft-server:2021.4.0-multiarch-latest -v -fsSL -o /dev/null https://launchermeta.mojang.com/mc/game/version_manifest.json

• Resolving timed out after 1225522907290 milliseconds
• Closing connection 0
  curl: (28) Resolving timed out after 1225522907290 milliseconds

container - adoptopenjdk:latest

pi@pi4ng:~ $ docker run --rm --entrypoint curl adoptopenjdk:latest -v -fsSL -o /dev/null https://launchermeta.mojang.com/mc/game/version_manifest.json

• Closing connection 0
  curl: (28) Timeout was reached

[itzg]

Since adoptopenjdk:latest fails the same way, then it's unfortunately an upstream issue that's beyond my control.

Please try multiarch or java15 tags from:

https://github.com/itzg/docker-minecraft-server#running-minecraft-server-on-different-java-version

[mrowek]

I'm receiving exactly the same outcomes as @vonloschz after every test provided by @itzg
When you mentioned that it can be DNS issue, the first culprit was PiHole. But after stopping pihole container, setting up DNS on my router to 1.1.1.1 later to 8.8.8.8, flushing DNS where I could, the outcome was the same

[itzg]

Bummer. You'll have to wait for the upstream base image to fix whatever is breaking this then :(

[mrowek]

can confirm that #755 is the same issue, after adding privileged: true everything goes as it should be

[itzg]

Maybe there was a kernel update that influenced this. What distro is everyone here running on rpi? Raspbian?

[vonloschz]

Raspberry Pi OS Lite

[mrowek]

Raspberrypi OS 32 bit
Quite fresh install (around 2weeks ago)

[itzg]

and would be interesting to see what uname -rv values might correlate with working systems vs not working ones. Meanwhile, I might simply add a note in the README about needing the privileged: true setting.

[vonloschz]

pi@pi4ng:~ $ uname -rv
5.4.83-v7l+ #1379 SMP Mon Dec 14 13:11:54 GMT 2020

pi@pi4ng:~ $ uname -a
Linux pi4ng 5.4.83-v7l+ #1379 SMP Mon Dec 14 13:11:54 GMT 2020 armv7l GNU/Linux

pi@pi4ng:~ $ cat /proc/cpuinfo | grep Revision
Revision : b03112

https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md

[mrowek]

root@raspberrypi:/home/pi# uname -rv
5.4.83-v7l+ #1379 SMP Mon Dec 14 13:11:54 GMT 2020

root@raspberrypi:/home/pi# cat /proc/cpuinfo | grep Revision
Revision : d03114

[vonloschz]

problem is maybe with image build over alpine:3.13.0 +

image base on alpine:3.11.0

pi@pi4ng:~ $ docker run --rm arm32v7/alpine:3.11.0 ping -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=117 time=9.538 ms
64 bytes from 8.8.8.8: seq=1 ttl=117 time=7.132 ms
64 bytes from 8.8.8.8: seq=2 ttl=117 time=22.946 ms

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 7.132/13.205/22.946 ms

image base on alpine:3.13.0 and more ...

pi@pi4ng:~ $ docker run --rm arm32v7/alpine:3.13.0 ping -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: clock_gettime(MONOTONIC) failed

[itzg]

problem is maybe with image build over alpine:3.13.0 +

FYI, none of my multi-architecture images (aka rpi) are based on Alpine. They are all Debian based.

[ErstBlack]

Looks like there might be a workaround here:
AdoptOpenJDK/openjdk-docker#469

After installing libseccomp2_2.5.1-1_armhf.deb via gdebi, I'm able to run multiarch-latest again

[itzg]

That's not just a workaround, it's the solution that others confirmed

#755 (comment)

Can we close this issue since package/library issues at the host level are beyond the control of what I can do in the image definition?

[github-actions]

This issue is stale because it has been open 30 days with no activity. Please add a comment describing the reason to keep this issue open.