search

itzg / docker-minecraft-server

Docker image that provides a Minecraft Server that will automatically download selected version at startup
https://docker-minecraft-server.readthedocs.io/
Apache License 2.0
9.49k stars 1.55k forks source link

Downloading minecraft_server..jar error Timeout #756

Closed vonloschz closed 2 years ago

vonloschz commented 3 years ago

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 commented 3 years ago

running under Raspberry Pi 4 2G.

itzg commented 3 years ago

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 commented 3 years ago

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

vonloschz commented 3 years ago

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

mrowek commented 3 years ago

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 commented 3 years ago

same error message with 2021.4.0-multiarch-latest

itzg commented 3 years ago

Can you try a couple of things:

vonloschz commented 3 years ago

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

vonloschz commented 3 years ago

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 commented 3 years ago

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

vonloschz commented 3 years ago

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

vonloschz commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

...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 commented 3 years ago

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]

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]

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

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

itzg commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

mrowek commented 3 years ago

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

itzg commented 3 years ago

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

vonloschz commented 3 years ago

Raspberry Pi OS Lite

mrowek commented 3 years ago

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

itzg commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Looks like there might be a workaround here: https://github.com/AdoptOpenJDK/openjdk-docker/issues/469

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

itzg commented 3 years ago

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

https://github.com/itzg/docker-minecraft-server/issues/755#issuecomment-781615497

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[bot] commented 2 years ago

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.