Auto Download failing with HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR

[mrgrosser]

Looking up latest version...
Downloading Bedrock server version 1.21.30.03 ...
curl: (92) HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2)
ERROR failed to download from https://www.minecraft.net/bedrockdedicatedserver/bin-linux/bedrock-server-1.21.30.03.zip
Double check that the given VERSION is valid
DEBU[0000] Using /data to match uid and gid
DEBU[0000] Resolved UID=0 from match path
DEBU[0000] Resolved GID=0 from match path

WGET fails from ubuntu 22.04 server. Made sure to apt update and upgrade everything. Restarted. Manually tried to WGET,
wget https://www.minecraft.net/bedrockdedicatedserver/bin-linux/bedrock-server-1.21.30.03.zip
--2024-09-23 11:48:12-- https://www.minecraft.net/bedrockdedicatedserver/bin-linux/bedrock-server-1.21.30.03.zip
Resolving www.minecraft.net (www.minecraft.net)... 23.76.205.33, 23.76.205.26
Connecting to www.minecraft.net (www.minecraft.net)|23.76.205.33|:443... connected.
HTTP request sent, awaiting response...
Tried putting that link in my browser and it downloads fine. Wondering if Minecraft/Microsoft is blocking that agent id now and it must come from a browser? Is there a way to just manually download and put it somewhere in the server for now to bypass?

[jacokok]

I honestly think you are onto something, without user agent it does not work and works fine if any user agent is available.

[jacokok]

I created simple pull request to include agent: #459
Tested locally and change seems to fix this problem.

[mrgrosser]

That fixed it! Thanks for the merge. Server is up and running.

[josephdpurcell]

Ay carumba! Thanks for figuring this out! Here was my test:

I modified my docker-compose.yml to have an entrypoint:

services:
  minecraft:
    entrypoint: ["bash"]

That allowed me to attach to the container because currently it fails and keeps restarting.

Then I did docker attach minecraft and confirmed that making the request failed:

root@af2456a50f08:/data# curl -I https://www.minecraft.net/bedrockdedicatedserver/bin-linux/bedrock-server-1.21.31.04.zip
curl: (92) HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2)

Then I tested the -A flag like so:

root@af2456a50f08:/data# curl -A "itzg/minecraft-bedrock-server" -I https://www.minecraft.net/bedrockdedicatedserver/bin-linux/bedrock-server-1.21.31.04.zip
HTTP/2 200 
content-length: 56027291
content-type: application/x-zip-compressed
content-md5: gPPO/pbSYdvJnG61s5DuDA==
last-modified: Mon, 30 Sep 2024 15:45:49 GMT
accept-ranges: bytes
etag: "0x8DCE166F5659C92"
server: Windows-Azure-Web/1.0 Microsoft-HTTPAPI/2.0
x-ms-request-id: d400f614-501e-007b-7d51-138a03000000
x-ms-version: 2018-03-28
mpulse_cdn_cache: HIT
mpulse_origin_time: 0
cache-control: max-age=160696
expires: Mon, 07 Oct 2024 15:57:23 GMT
date: Sat, 05 Oct 2024 19:19:07 GMT
server-timing: ak_p; desc="1728155946938_1749913683_83833968_9026_15587_18_40_15";dur=1

@itzg THANK YOU SOOOO much for this project and providing a way to track these types of issues and for issuing new fixes so quickly. I'll happily patiently await a new image.

[itzg]

@josephdpurcell the fixed image had already been pushed.

[josephdpurcell]

Woohoo!

I'm not sure the best way to do this, I did docker compose up and I thought it usually runs the new container? But, it didn't, so I did docker compose pull and then docker compose up and it worked.

THANK YOU!!!

[itzg]

Yep, a pull is always needed. Your approach is exactly right. I believe Docker's intent is to avoid surprise updates.

[tuknet2018]

I have the same issue. I’ve tried using Podman and Docker on different servers, and while all the containers have internet access, the problem persists: curl cannot download the .zip file. I attempted to change the entry point to /bin/sh and manually download the .zip with the agent options for curl. If I try curl without the -A parameter, it doesn't work. Downloading the file normally via the endpoint seems impossible.

Create a new server, pull new images and the latest , and the same problem continue.

[root@podman world_seed]# podman images
REPOSITORY TAG IMAGE ID CREATED SIZE
docker.io/itzg/minecraft-bedrock-server 2024.9.0 507cb46531db 13 days ago 185 MB
docker.io/itzg/minecraft-bedrock-server latest 28e90626f0e4 2 weeks ago 185 MB

[root@docker world_seed]# docker images| grep bedrock
docker.io/itzg/minecraft-bedrock-server 2024.9.0 507cb46531db 13 days ago 180 MB
docker.io/itzg/minecraft-bedrock-server latest 28e90626f0e4 2 weeks ago 180 MB

On centos or redhat , after pull the image, a recreate the container the problem continue.

[root@podman world_seed]# podman run -d -it --name mc -e EULA=TRUE -e LEVEL_SEED=822815728642535760 -p 88888:19132/udp -v /world_seed:/data itzg/minecraft-bedrock-server:latest
7b17f4b032d92d6d9d92bb0e955482e144a93adefa9882db034ce67dabb32174
[root@podman world_seed]# podman logs mc
DEBU[0000] Using /data to match uid and gid
DEBU[0000] Resolved UID=65534 from match path
DEBU[0000] Resolved GID=65534 from match path

[josephdpurcell]

@tuknet2018 Can you share the output of this command when running within the container:

curl -A "itzg/minecraft-bedrock-server" -I https://www.minecraft.net/bedrockdedicatedserver/bin-linux/bedrock-server-1.21.31.04.zip

[tuknet2018]

[root@podman minecraft]# curl -A "itzg/minecraft-bedrock-server" -I https://www.minecraft.net/bedrockdedicatedserver/bin-linux/bedrock-server-1.21.31.04.zip
HTTP/2 200
content-length: 56027291
content-type: application/x-zip-compressed
content-md5: gPPO/pbSYdvJnG61s5DuDA==
last-modified: Mon, 30 Sep 2024 15:45:49 GMT
accept-ranges: bytes
etag: "0x8DCE166F5659C92"
server: Windows-Azure-Web/1.0 Microsoft-HTTPAPI/2.0
x-ms-request-id: 089264e1-901e-0016-1c50-133e48000000
x-ms-version: 2018-03-28
mpulse_origin_time: 399
mpulse_cdn_cache: MISS
cache-control: max-age=190708
expires: Mon, 14 Oct 2024 02:07:37 GMT
date: Fri, 11 Oct 2024 21:09:09 GMT
server-timing: ak_p; desc="1728680949498_388075279_113028191_17635_8345_15_27_15";dur=1

From a server where run the container, from container can not try because the container not start.

[tuknet2018]

/`From a docker container

curl -A "itzg/minecraft-bedrock-server" -I https://www.minecraft.net/bedrockdedicatedserver/bin-linux/bedrock-server-1.21.31.04.zip

curl: (6) getaddrinfo() thread failed to start

/

[josephdpurcell]

@tuknet2018 That error appears to be different than what is reported on this issue. The root cause of this issue was resolved by changing the user agent.

The root cause of your curl error should not be resolved by just changing the user agent since it appears it cannot resolve DNS.

Can you think of any reasons that DNS would not be resolved?

[tuknet2018]

For i can test , y change the entrypoint for test curl and resolution, i think the problem is curl

docker run -d -it --entrypoint /bin/sh --name mc -e EULA=TRUE -p 19131:19132/udp docker.io/itzg/minecraft-bedrock-server:2024.10.0

[root@docker world_seed]# docker run -d -it --entrypoint /bin/sh --name mc -e EULA=TRUE -e LEVEL_SEED=1222690162574629 -p 20131:19132/udp itzg/minecraft-bedrock-server
f540f97fe5cf94540620327ac76dba70504f54ed41394327c8d01e8f024b211d
[root@docker world_seed]# docker exec -it mc sh

curl -I https://www.google.com

curl: (6) getaddrinfo() thread failed to start

head /etc/resolv.conf

Generated by NetworkManager

nameserver 8.8.8.8

openssl s_client -connect 8.8.8.8:53

CONNECTED(00000003)
.....................

openssl s_client -connect minecraft.net:443

CONNECTED(00000003)
.....................

Launching entrypoint /opt/bedrock-entry.sh whit set -x

++ basename https://www.minecraft.net/bedrockdedicatedserver/bin-linux/bedrock-server-1.21.31.04.zip

• TMP_ZIP=/tmp/bedrock-server-1.21.31.04.zip
• echo 'Downloading Bedrock server version 1.21.31.04 ...'
  Downloading Bedrock server version 1.21.31.04 ...
• curl -o /tmp/bedrock-server-1.21.31.04.zip -A itzg/minecraft-bedrock-server -fsSL https://www.minecraft.net/bedrockdedicatedserver/bin-linux/bedrock-server-1.21.31.04.zip
  curl: (6) getaddrinfo() thread failed to start
• echo 'ERROR failed to download from https://www.minecraft.net/bedrockdedicatedserver/bin-linux/bedrock-server-1.21.31.04.zip'
  ERROR failed to download from https://www.minecraft.net/bedrockdedicatedserver/bin-linux/bedrock-server-1.21.31.04.zip
• echo ' Double check that the given VERSION is valid'
  Double check that the given VERSION is valid
• exit 2

[josephdpurcell]

I have to say that is puzzling @tuknet2018. Can you make any curl requests from within the container or do they all fail with getaddrinfo?

The fact that OpenSSL can start a connection is baffling, because it suggests that it's able to resolve DNS.

I see some spooky curl issues that might be related:

• curl: (6) getaddrinfo() thread failed to start curl/curl#10871
• getaddrinfo thread failed to start curl/curl#6495

I suggest opening a new ticket since your issue is distinct from what is reported here.

[tuknet2018]

I found the problem, with centos, redhat ... , in next post i explain detailed, but fast fix for RedHat, Docker ... , i need to create container with:
docker run -d -it --name mc -e EULA=TRUE -e LEVEL_SEED=1222690162574629 --security-opt seccomp=unconfined -p 19131:19132/udp -v bedrockcontainer:/data itzg/minecraft-bedrock-server

The problem/bug is callsystem and seccomp
https://bugzilla.redhat.com/show_bug.cgi?id=1990469

[McFcologne]

I just fetched the latest version of itzg/minecraft-bedrock-server, but still have this issue. Any advice, how to get it running? I have no chance to do anything inside to container, since the container manager on synology is shutting down the container after the error

[josephdpurcell]

@McFcologne Can you share details? Are you using docker compose? If so try docker pull. See also #458 (comment)

[McFcologne]

Im using the synology container manager and there is no way to actively pull if there is no update, but i remember there was an update a couple of days ago:

[itzg]

Can always check if your system actually pulled the latest image by comparing sha's at

https://hub.docker.com/r/itzg/minecraft-bedrock-server/tags

[McFcologne]

seems to be definitely not the latest:
https://hub.docker.com/layers/itzg/minecraft-bedrock-server/latest/images/sha256-f6127814f654a143d8f7be67ca26404638b5abf3eed7d4f6c4a3072f98f92cd7?context=explore

sha256:f8b7b548e8ab2a7b5915253b4e4e096a141e4fd98c93764210752ece8bbf1a84

Container manager shows:

sha256:85063b8a92a39ee9fe69e23a32517c54c691bd5ec684a0dba3eadaad92f4fe73

there is definitely a mismatch

I opened a ticket at Synology to clearify what could be the issue, thank you

[davralin]

Not to be overly sarcastic, but it seems like most of the recent issues are all related to the fact that semantic versioning is not used for the container image.

[itzg]

I do cut releases and thank you for the indirect reminder.

[itzg]

FYI https://github.com/itzg/docker-minecraft-bedrock-server/releases/tag/2024.10.0 already included the fix. So proper use of pulling the semantic versioned image would also fix user reported issues.

[tuknet2018]

Please include the following parameter in the docker run or docker create command. I have an issue downloading the new version, but the problem with curl is different; it is not related to the header but to a system call issue.

--security-opt seccomp=unconfined

docker run -d -it --name mc -e EULA=TRUE --security-opt seccomp=unconfined -p 19132:19132/udp -v bedrockcontainer:/data itzg/minecraft-bedrock-server

If this parameter solves your problem, try configuring special security for this container, as this option allows all security permissions.

[davralin]

I do cut releases and thank you for the indirect reminder.

Right, I misremembered why I was here - however, the default in the helm-chart is latest.

https://github.com/itzg/minecraft-server-charts/blob/master/charts/minecraft-bedrock/values.yaml#L4

[McFcologne]

pulled the latest docker image, still the same issue