Container exits immediately after starting

Question

Container exits immediately after starting

Mootch opened this issue 2 years ago · comments

Hi,

I'm running a raspberry pi on Ubuntu 20.04.4 LTS (GNU/Linux 5.4.0-1052-raspi aarch64). I built a docker image from your dockerfile since the Docker Hub only has an amd64 image. When I start a container from the image, it appears to go through the set-up but then exits immediately. I don't see any specific error message when it exits. What should I be looking for to address this?

Thanks for putting this together!

James A. Chambers · Answer 1 · Fri May 13 2022 00:01:36 GMT+0800 (China Standard Time)

Hey Mootch,

I was surprised by this but when I tried the image on Raspberry Pi as is it "just worked" on my Pi 400:

pi@pi400:~ $ uname -a
Linux pi400 5.10.103-v7l+ #1529 SMP Tue Mar 8 12:24:00 GMT 2022 armv7l GNU/Linux
pi@pi400:~ $ sudo docker run -it -v minecraftbe2:/minecraft -p 19132:19132/udp -p 19132:19132 05jchambers/legendary-bedrock-container:latest
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm/v7) and no specific platform was requested
Minecraft Bedrock Server Docker script by James A. Chambers
Latest version always at https://github.com/TheRemote/Legendary-Bedrock-Container
Don't forget to set up port forwarding on your router!  The default port is 19132
Ports used - IPV4: 19132 - IPV6: 19133
Backing up server (to minecraftbe/backups folder)
Backing up server (multiple cores) to minecraftbe/backups folder
worlds/
worlds/Bedrock level/
worlds/Bedrock level/levelname.txt
worlds/Bedrock level/level.dat
worlds/Bedrock level/db/
worlds/Bedrock level/db/CURRENT
worlds/Bedrock level/db/MANIFEST-000004
worlds/Bedrock level/db/000005.log
worlds/Bedrock level/level.dat_old
Checking for the latest version of Minecraft Bedrock server ...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  310k    0  310k    0     0   254k      0 --:--:--  0:00:01 --:--:--  260k
Minecraft Bedrock server is up to date...
Starting Minecraft server...

After this the console loads normally. Do you get that same platform based warning for the image? Was it for aarch64 instead of arm?

I thought this Pi was running the 64 bit flavor of Raspberry Pi OS but apparently it's not. I would expect the 32 bit version to have even less of a chance of working though.

I did find this: https://stackoverflow.com/questions/67458621/how-to-run-amd64-docker-images-on-arm64-host-platform

It sounds like this should be possible period (through the Rosetta engine) but you may have to use a modified startup launch line. I'm not sure why you would have to use it and I didn't encounter this but it does look like it's a thing. The modified startup would be something like:

sudo docker run -it -v minecraftbe2:/minecraft -p 19132:19132/udp -p 19132:19132 --platform linux/amd64 05jchambers/legendary-bedrock-container:latest

If this works let me know and I will definitely add this to the documentation. Mine launched normally again with this but it no longer had the warning about there not being an ARM image. My volume name was "minecraft2" so you'd replace that with your volume. I also tried a volume3 to make sure it worked from scratch.

Thanks for investigating and reporting this!

Mootch · Answer 2 · Fri May 13 2022 01:16:06 GMT+0800 (China Standard Time)

Thanks for the response. Adding the --platform option got it to run successfully. I'm not sure if that was causing the issue before or something else, but it seems to be working now.

James A. Chambers · Answer 3 · Fri May 13 2022 01:32:31 GMT+0800 (China Standard Time)

Thank you for following up with this on me and being my first issue / feedback I've got for the container!

I'm not sure why I didn't need it either. It could be that if you are running it on 32 bit then Docker makes some assumptions that it doesn't make on 64 bit. It could also be Docker defaults or configuration related meaning whoever packaged our distro's package could be influencing some tiny setting that does whatever mine did automatically and that isn't present in your version/distro/package.

I'll definitely get this added to the documentation. Undoubtedly other people have already encountered this as I think the likelihood of people reporting / filing issues is probably less than 10% and maybe even a lot less than that. Thanks a ton!

James A. Chambers · Answer 4 · Fri May 13 2022 01:48:02 GMT+0800 (China Standard Time)

I found a better way to do this. I am basically doing it for you in the Dockerfile now with:

# Use current Ubuntu LTS version
FROM ubuntu:20.04

to:

# Use current Ubuntu LTS version
FROM --platform=linux/amd64 ubuntu:20.04

So theoretically you should no longer need that parameter. Thanks again!

Mootch · Answer 5 · Fri May 13 2022 03:12:39 GMT+0800 (China Standard Time)

Thanks for looking into this. I'll try it with the update when I get a chance.

Jeppe Hasseriis · Answer 6 · Sun May 22 2022 03:01:31 GMT+0800 (China Standard Time)

Hello

I just pulled the image but I'm getting this on my RPI 4:

$ docker run -it -v /home/pi/minecraft:/minecraft -p 19132:19132/udp -p 19132:19132 -p 19133:19133/udp -p 19133:19133 05jchambers/legendary-bedrock-container:latest
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
standard_init_linux.go:228: exec user process caused: exec format error

According to your blog post comment (https://jamesachambers.com/legendary-minecraft-bedrock-container/#comment-13460) this shouldn't happen with the latest version, but apparently it still do.

Adding --platform unfortunately doesn't help.

$ docker run -it -v /home/pi/minecraft:/minecraft -p 19132:19132/udp -p 19132:19132 -p 19133:19133/udp -p 19133:19133 --platform linux/amd64 05jchambers/legendary-bedrock-container:latest
standard_init_linux.go:228: exec user process caused: exec format error

Maybe this can help:

$ uname -a
Linux raspberrypi 5.10.17-v8+ #1414 SMP PREEMPT Fri Apr 30 13:23:25 BST 2021 aarch64 GNU/Linux

James A. Chambers · Answer 7 · Sun May 22 2022 03:27:51 GMT+0800 (China Standard Time)

Can you try the following commands:

sudo apt-get install binfmt-support qemu-user-static

It's your packages I think. From https://docs.docker.com/desktop/multi-arch/ :

Docker Desktop provides binfmt_misc multi-architecture support, which means you can run containers for different Linux architectures such as arm, mips, ppc64le, and even s390x.

This does not require any special configuration in the container itself as it uses [qemu-static](https://wiki.qemu.org/Main_Page) from the Docker for Mac VM. Because of this, you can run an ARM container, like the arm32v7 or ppc64le variants of the busybox image.

My guess is your system is missing binfmt-support or possibly qemu-user-static. Can you try that and let's see if it works after that!

I found more requirements here: https://medium.com/@artur.klauser/building-multi-architecture-docker-images-with-buildx-27d80f7e2408

— Host installation:
— — QEMU installed: To execute foreign CPU instructions on the host, QEMU simulators need to be installed. They need to be statically linked since dynamic library resolution depends on those dynamic libraries being visible in the file system at time of use, which is not typically the case inside a container or chroot environment.
— — binfmt-support package >= 2.1.7: You need to install a package that contains an update-binfmts binary new enough to understand the fix-binary (F) flag and actually use it when registering QEMU simulators.

I think you may have finally helped me solve this mystery. It appears for it to run smoothly on ARM you need qemu-user-static and binfmt-support installed via sudo apt install binfmt-support qemu-user-static. I happened to have these packages on my ARM systems already because I use them for the standalone version of the script but it definitely explains why I never encountered this.

Let me know if this takes care of it for you as it will need to be added to the documentation that when running on ARM you need these packages to run multiarch images!

I found some documentation saying that this can work if I install it myself inside the container and that it isn't "required" on the host system if done that way. I just added this. Can you try pulling the latest and running again?

Jeppe Hasseriis · Answer 8 · Sun May 22 2022 04:40:36 GMT+0800 (China Standard Time)

Thanks for all the suggestions!

I started with this sudo apt install binfmt-support qemu-user-static and this helped to start the server, but I'm getting a lot of these messages:

...
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unsupported setsockopt level=41 optname=20
Unsupported setsockopt level=41 optname=20
Unsupported setsockopt level=41 optname=34
...

Furthermore it takes forever to connect to the server, I'm stuck on "connecting to server...". 1 time it connected after several minutes, but I haven't had success since.

Installing qemu (sudo apt install qemu) didn't help unfortunately.

You also asked me to try this

$ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
standard_init_linux.go:228: exec user process caused: exec format error

and now the minecraft docker container won't start either :-(

standard_init_linux.go:228: exec user process caused: exec format error

I'm gonna start over removing the container and image and re-pulling the image now.

Jeppe Hasseriis · Answer 9 · Sun May 22 2022 04:43:23 GMT+0800 (China Standard Time)

Not going well this time again

$ docker run -it -v /home/pi/minecraft:/minecraft -p 19132:19132/udp -p 19132:19132 -p 19133:19133/udp -p 19133:19133 05jchambers/legendary-bedrock-container:latest
Unable to find image '05jchambers/legendary-bedrock-container:latest' locally
latest: Pulling from 05jchambers/legendary-bedrock-container
125a6e411906: Pull complete
a2c7410802ad: Pull complete
783ba31104b6: Pull complete
c29e6f0d3226: Pull complete
c2415989ddc5: Pull complete
48489d43ba6b: Pull complete
c45b697d57e1: Pull complete
df2e4e52dda7: Pull complete
Digest: sha256:200eac5468433672ff5839a30d6baaab60a3386a9f79a78ca4974487136ce4f9
Status: Downloaded newer image for 05jchambers/legendary-bedrock-container:latest
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
standard_init_linux.go:228: exec user process caused: exec format error

Jeppe Hasseriis · Answer 10 · Sun May 22 2022 04:48:16 GMT+0800 (China Standard Time)

I re-installed qemu-user-static and this helped, but I'm still getting those messages:

Minecraft Bedrock Server Docker script by James A. Chambers
Latest version always at https://github.com/TheRemote/Legendary-Bedrock-Container
Don't forget to set up port forwarding on your router!  The default port is 19132
Ports used - IPV4: 19132 - IPV6: 19133
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Backing up server (to minecraftbe/backups folder)
Backing up server (multiple cores) to minecraftbe/backups folder
worlds/
worlds/Bedrock level/
worlds/Bedrock level/levelname.txt
worlds/Bedrock level/level.dat
worlds/Bedrock level/level.dat_old
worlds/Bedrock level/db/
worlds/Bedrock level/db/000005.ldb
worlds/Bedrock level/db/000008.ldb
worlds/Bedrock level/db/MANIFEST-000007
worlds/Bedrock level/db/CURRENT
worlds/Bedrock level/db/000009.log
Checking for the latest version of Minecraft Bedrock server ...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:--  0:00:02 --:--:--     0
100  310k    0  310k    0     0  99777      0 --:--:--  0:00:03 --:--:--   98k
Minecraft Bedrock server is up to date...
Starting Minecraft server...
tCould not write /var/run/utmp: No such file or directory  ��
[2022-05-21 20:44:59] NO LOG FILE! - setting up server logging...
[2022-05-21 20:44:59] [2022-05-21 20:44:59:562 INFO] Starting Server
[2022-05-21 20:44:59] [2022-05-21 20:44:59:566 INFO] Version 1.18.33.02
[2022-05-21 20:44:59] [2022-05-21 20:44:59:567 INFO] Session ID a26018f7-8f4e-496c-b383-a6e3d431c561
[2022-05-21 20:44:59] [2022-05-21 20:44:59:608 INFO] Level Name: Bedrock level
[2022-05-21 20:44:59] [2022-05-21 20:44:59:683 INFO] Game mode: 0 Survival
[2022-05-21 20:44:59] [2022-05-21 20:44:59:684 INFO] Difficulty: 1 EASY
[2022-05-21 20:45:00] [2022-05-21 20:45:00:095 INFO] opening worlds/Bedrock level/db
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unsupported setsockopt level=41 optname=20
Unsupported setsockopt level=41 optname=20
Unsupported setsockopt level=41 optname=34
[2022-05-21 20:45:35] [2022-05-21 20:45:35:853 INFO] IPv4 supported, port: 19132
[2022-05-21 20:45:35] [2022-05-21 20:45:35:863 INFO] IPv6 not supported
[2022-05-21 20:45:45] [2022-05-21 20:45:45:427 INFO] Server started.
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unsupported setsockopt level=41 optname=20
Unsupported setsockopt level=41 optname=20
Unsupported setsockopt level=41 optname=34
[2022-05-21 20:45:45] [2022-05-21 20:45:45:578 INFO] IPv4 supported, port: 55966
[2022-05-21 20:45:45] [2022-05-21 20:45:45:578 INFO] IPv6 not supported

James A. Chambers · Answer 11 · Sun May 22 2022 06:06:53 GMT+0800 (China Standard Time)

Thanks for your investigation into this!

Can you do a:

uname -a
qemu-aarch64-static --version

My Ubuntu 20.02 desktop gives 6.2.0 and my Raspberry Pi gives 5.2.0 for the QEMU version.

I suspect that this is significantly older than that. I remember seeing these errors years ago when Raspberry Pi was on an older version of QEMU like that. It doesn't actually hurt anything to have those warnings

I'd remove qemu, qemu-user-static and binfmt-utilities now and try running the container and let it use my versions (definitely newer). I'm not sure if this will work yet but the documentation I read said it could work to have them on either side.

Mine looked like this:

pi@pi400:~ $ qemu-x86_64-static --version
qemu-x86_64 version 5.2.0 (Debian 1:5.2+dfsg-11+deb11u2)
Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers
pi@pi400:~ $ uname -a
Linux pi400 5.10.103-v7l+ #1529 SMP Tue Mar 8 12:24:00 GMT 2022 armv7l GNU/Linux
pi@pi400:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

pi@pi400:~ $ sudo docker run -it -v minecraftbe:/minecraft -p 19132:19132/udp -p 19132:19132 -p 19133:19133/udp -p 19133:19133 05jchambers/legendary-bedrock-container:latest
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm/v7) and no specific platform was requested
Minecraft Bedrock Server Docker script by James A. Chambers
Latest version always at https://github.com/TheRemote/Legendary-Bedrock-Container
Don't forget to set up port forwarding on your router!  The default port is 19132
Ports used - IPV4: 19132 - IPV6: 19133
Backing up server (to minecraftbe/backups folder)
Backing up server (multiple cores) to minecraftbe/backups folder
worlds/
worlds/Bedrock level/
worlds/Bedrock level/levelname.txt
worlds/Bedrock level/level.dat
worlds/Bedrock level/db/
worlds/Bedrock level/db/CURRENT
worlds/Bedrock level/db/MANIFEST-000002
worlds/Bedrock level/db/000003.log
worlds/Bedrock level/level.dat_old
Checking for the latest version of Minecraft Bedrock server ...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  310k    0  310k    0     0   254k      0 --:--:--  0:00:01 --:--:--  260k
Minecraft Bedrock server is up to date...
Starting Minecraft server...
[2022-05-21 22:01:56] NO LOG FILE! - setting up server logging...
[2022-05-21 22:01:56] [2022-05-21 22:01:56:551 INFO] Starting Server
[2022-05-21 22:01:56] [2022-05-21 22:01:56:556 INFO] Version 1.18.33.02
[2022-05-21 22:01:56] [2022-05-21 22:01:56:556 INFO] Session ID 9cecdcc7-6864-4168-9b09-218a630bed2f
[2022-05-21 22:01:56] [2022-05-21 22:01:56:595 INFO] Level Name: Bedrock level
[2022-05-21 22:01:56] [2022-05-21 22:01:56:645 INFO] Game mode: 0 Survival
[2022-05-21 22:01:56] [2022-05-21 22:01:56:646 INFO] Difficulty: 1 EASY
[2022-05-21 22:01:57] [2022-05-21 22:01:57:867 INFO] opening worlds/Bedrock level/db
[2022-05-21 22:02:30] [2022-05-21 22:02:30:845 INFO] IPv4 supported, port: 19132
[2022-05-21 22:02:30] [2022-05-21 22:02:30:856 INFO] IPv6 not supported
[2022-05-21 22:02:38] [2022-05-21 22:02:38:241 INFO] Server started.
[2022-05-21 22:02:39] [2022-05-21 22:02:39:419 INFO] IPv4 supported, port: 34272
[2022-05-21 22:02:39] [2022-05-21 22:02:39:419 INFO] IPv6 not supported

No warnings with this QEMU version. I'd like to see if it can get it working with the built in one. I'm going to remove QEMU from my Pi and try to do it from the container side. I'm not sure if this will work yet but I read that it should. If it does then you would delete that old version your OS installed and just let it use mine from the latest Ubuntu.

Let's see what yours looks like here!

James A. Chambers · Answer 12 · Sun May 22 2022 12:30:30 GMT+0800 (China Standard Time)

I redesigned the entire container around this issue. Thank you to everyone for reporting this.

Now there actually is an image. For each platform! Go ahead and do a:

docker pull 05jchambers/legendary-bedrock-container:latest

and now it will select the right image for your platform. Can anyone who was having trouble with this give the latest one a try?

Jeppe Hasseriis · Answer 13 · Mon May 23 2022 02:12:48 GMT+0800 (China Standard Time)

Can you do a:
uname -a
qemu-aarch64-static --version

$ uname -a
Linux raspberrypi 5.10.17-v8+ #1414 SMP PREEMPT Fri Apr 30 13:23:25 BST 2021 aarch64 GNU/Linux

$ qemu-aarch64-static --version
qemu-aarch64 version 3.1.0 (Debian 1:3.1+dfsg-8+deb10u8)
Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers

You're right, it's a really old version!

So I removed the container, qemu, qemu-user-static, binfmt-support and started over:

$ docker run -it -v /home/pi/minecraft:/minecraft -p 19132:19132/udp -p 19132:19132 -p 19133:19133/udp -p 19133:19133 05jchambers/legendary-bedrock-container:latest

Minecraft Bedrock Server Docker script by James A. Chambers
Latest version always at https://github.com/TheRemote/Legendary-Bedrock-Container
Don't forget to set up port forwarding on your router!  The default port is 19132
Ports used - IPV4: 19132 - IPV6: 19133
Backing up server (to minecraftbe/backups folder)
Backing up server (multiple cores) to minecraftbe/backups folder
worlds/
worlds/Bedrock level/
worlds/Bedrock level/levelname.txt
worlds/Bedrock level/level.dat
worlds/Bedrock level/level.dat_old
worlds/Bedrock level/db/
worlds/Bedrock level/db/000461.ldb
worlds/Bedrock level/db/000459.log
worlds/Bedrock level/db/CURRENT
worlds/Bedrock level/db/MANIFEST-000031
Checking for the latest version of Minecraft Bedrock server ...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100  310k    0  310k    0     0   408k      0 --:--:-- --:--:-- --:--:--  408k
Minecraft Bedrock server is up to date...
Starting Minecraft server...
t/bin/bash: line 1: /minecraft/bedrock_server: cannot execute binary file: Exec format error
t[screen is terminating]

The error messages are gone, but the server seem to fail.

Jeppe Hasseriis · Answer 14 · Mon May 23 2022 02:16:31 GMT+0800 (China Standard Time)

Forgot this

$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Jeppe Hasseriis · Answer 15 · Mon May 23 2022 02:27:53 GMT+0800 (China Standard Time)

Dunno if this is useful to you

$ readelf -h bedrock_server | grep 'Class\|File\|Machine'
  Class:                             ELF64
  Machine:                           Advanced Micro Devices X86-64

James A. Chambers · Answer 16 · Mon May 23 2022 02:43:46 GMT+0800 (China Standard Time)

Hey cenobitedk,

Great, that helps! So basically I uninstalled qemu on my Pi as well as binfmt-utils. It took about 9 hours of constant failed builds but it doesn't use your system's QEMU at all anymore. It's just built in basically.

I did this to get around the system QEMU being old (or not present). I don't want this to be a requirement. It's all self contained now and there's separate images for each. I assume you did pull the latest here as you would still be getting that platform warning on the older version.

Is this real Debian? I assume it is because my cat /etc/os-release does say Raspbian. It may be worth it for you to upgrade to Bullseye. This is pretty easy. You pretty much just edit your apt sources.list file and then let apt upgrade it. There's a guide on how to do this here: https://www.cyberciti.biz/faq/update-upgrade-debian-10-to-debian-11-bullseye/

There's another possibility. Maybe something isn't set up quite right for aarch64 and I haven't tested this yet. I'm positive with armv71 (32 bit) that you don't need QEMU as I completely deleted it from my system and none of that stuff we talked about earlier applies anymore (it's all done in the container).

I'm mentioning upgrading your OS though because I wonder if it is potentially Docker version related. Like my Docker on my Pi is giving this version:

pi@pi400:~ $ docker version
Client:
 Version:           20.10.5+dfsg1
 API version:       1.41
 Go version:        go1.15.9
 Git commit:        55c4c88
 Built:             Sat Dec  4 10:53:03 2021
 OS/Arch:           linux/arm
 Context:           default
 Experimental:      true

Server:
 Engine:
  Version:          20.10.5+dfsg1
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.15.9
  Git commit:       363e9a8
  Built:            Sat Dec  4 10:53:03 2021
  OS/Arch:          linux/arm
  Experimental:     false
 containerd:
  Version:          1.4.13~ds1
  GitCommit:        1.4.13~ds1-1~deb11u1
 runc:
  Version:          1.0.0~rc93+ds1
  GitCommit:        1.0.0~rc93+ds1-5
 docker-init:
  Version:          0.19.0
  GitCommit:

The containers are all built on x86_64 using QEMU which means it must be working to build the image (otherwise it fails). That's why my mind is running to these other things as well.

I think I may need to do a aarch64 install just to confirm this! I have a Pi next to me that's not being used and may already have a 64 bit install on it so I will definitely try with aarch64 today to see if this is architecture related or not!

Jeppe Hasseriis · Answer 17 · Mon May 23 2022 03:25:21 GMT+0800 (China Standard Time)

Is this real Debian?

Yeah it's Raspbian. I'm not 100% sure but I'm almost certain that I followed your guide here: https://jamesachambers.com/where-to-get-the-64-bit-raspberry-pi-os-image-for-pi-4-400/

Sounds like upgrading would be ideal. However, this PI is also running my Home Assistant and Unifi Controller along with Esphome, Mosquitto and Portainer (all as containers), so I'm reluctant to just do the upgrade right away. I don't have a good backup solution running so if it goes down I'm screwed.

As you know, RPi's are not in abundance currently, so I only have this RPi 4 currently (except for an old RPi (1) Model B). But I believe a RPi 3 would also do the job if I can find one used, right?

Btw, my docker version is good.

$ docker version
Client: Docker Engine - Community
 Version:           20.10.8
 API version:       1.41
 Go version:        go1.16.6
 Git commit:        3967b7d
 Built:             Fri Jul 30 19:55:21 2021
 OS/Arch:           linux/arm64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.8
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.6
  Git commit:       75249d8
  Built:            Fri Jul 30 19:53:34 2021
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.4.10
  GitCommit:        8848fdb7c4ae3815afcc990a8a99d663dda1b590
 runc:
  Version:          1.0.2
  GitCommit:        v1.0.2-0-g52b36a2
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

James A. Chambers · Answer 18 · Mon May 23 2022 04:00:32 GMT+0800 (China Standard Time)

Hey cenobitedk,

I'm glad you brought this up because when I went downstairs to connect my Pi the air conditioners draining pipe had backed up and there was about 1/2 an inch of water right by all my cryptocurrency miners (it actually got a couple of my wife's wet, I told her not to leave them on the floor!).

I've got that under control and just powered on the Pi and am going to try here on aarch64 and see if I can figure out what the problem is here!

James A. Chambers · Answer 19 · Mon May 23 2022 05:02:20 GMT+0800 (China Standard Time)

Okay, I did a completely clean install today and I can confirm I'm seeing a problem here. It's not you (and I suspected as much which is why I busted out the test device).

I will get it working and then post a followup for aarch64!

James A. Chambers · Answer 20 · Mon May 23 2022 07:33:04 GMT+0800 (China Standard Time)

Alright, I finally have it here. It wasn't easy but I think it may have fixed it for more than just aarch64.

Can you do a docker pull and try running now?

Jeppe Hasseriis · Answer 21 · Mon May 23 2022 23:08:12 GMT+0800 (China Standard Time)

I pulled the latest version and works great! No error messages or anything! Great work, thank you!

Only problem I have no is that it takes forever to load the game when connecting, and I quickly see unrendered areas. I'm suspecting IPv6 to be an issue, but I'm not sure at all. I'll try to get my docker env to support IPv6

James A. Chambers · Answer 22 · Mon May 23 2022 23:18:55 GMT+0800 (China Standard Time)

Hey cenobitedk,

That is great news, thank you so much for following up and letting me know that got it for you!

So the speed of this is going to vary widely depending on the ARM device. Anything that isn't x86_64 does have a layer of emulation. On the latest container this is only bedrock_server. The container's OS and architecture are now native.

The devices that will do the best are probably ones with lower core counts and higher clock speed. While Minecraft Bedrock isn't single threaded it is considered single "cored" meaning most of the game logic is in fact only using one CPU core.

Unfortunately the Pi 4 for example is a device with 4 low powered cores. The 4 cores are usually great but Minecraft is not great at leveraging the additional cores like I mentioned. It would actually be better if the Pi was dual cored with higher single core clock speeds (and Minecraft is not the only software that likes lower core counts with high clock speeds).

Despite this the most important thing you can do to improve performance on the Pi is to switch to a SSD. The SD card is likely your bottleneck (assuming you are using one). This is the one thing in your control you can do basically. It still won't be perfect on a Pi 4 though. I'm expecting the Pi 5 to be pretty much perfect though as it will address a lot of the current bottlenecks.

If Microsoft would release a native ARM dedicated server build this would completely solve it. It's the emulation + the SD card that you are hitting when you are travelling quickly across the world. What you are literally seeing is the Pi waiting to generate the new chunks and write them to disk (this is why a SSD helps especially with the specific lag you are seeing).

I'd be curious if the networking has any impact. My guess is that the bottlenecks are what I was saying earlier based on my experience from my previous project (which can run it natively on the Pi in the standalone version but with the same limitations).

Overclocking the Pi's CPU does have a noticeable impact. If you have a SSD then the CPU becomes the bottleneck. It's pretty easy and safe to overclock these. If you want to try this I frequently use the "middle" overclocking settings on my Pi 4s without really any incident or instability: https://www.seeedstudio.com/blog/2020/02/12/how-to-safely-overclock-your-raspberry-pi-4-to-2-147ghz/. This person takes it to several different overclocking levels and if you pick the lower or medium ones you can get some "free" performance gains from this. If you go too high you want some sort of cooling case / airflow.

Hopefully that gives you some ideas on where to start!

Jeppe Hasseriis · Answer 23 · Tue May 24 2022 02:30:59 GMT+0800 (China Standard Time)

Thank you so much, this is really helpful!

I'm actually running the system on a 64GB Sandisk Flash disk and not the SD card. However, I do experience some kind of bottleneck and most specifially when pulling docker images. It starts off in great speed and then drops to something that reminds me of 56K modem, so sometimes it takes forever to pull images.
I'm gonna see if I can test continuous read/write speed to the flash disk and see how it turns out.

I'm currently running machine with passive cooling and it's around 50° celcius, so that works great, but I'll see what happens with overclocking. Could be interesting to try.

Btw, we can move the speed talk to another issue if you want, now the core problem is fixed.

James A. Chambers · Answer 24 · Tue May 24 2022 04:03:27 GMT+0800 (China Standard Time)

No problem at all! I actually have a specialty site for benchmarking storage for the Pi at https://pibenchmarks.com. It's basically a one-liner to run the benchmark (at the top of the site).

You're definitely on the right track here. The Docker pulling you are seeing is also bottlenecking. It does feel like a 56K modem when it starts doing this. When I did my testing I used a SD card so I got a little bit of this too. It's very "spotty" where it will bottleneck and get stuck for a while then it will seem to go back to full speed again.

This is definitely some bottlenecking. Unless the SanDisk flash drive is one of their SSD models (basically these look like USB thumb drives but are actually real SSDs) it is very likely to perform about the same or possibly slightly worse than a SD card.

I may be able to use a different emulator than QEMU to speed things up as well but the bottlenecking on storage will not go away from this (it would help with the CPU load though). This would be called box64 and it's only an option on aarch64 specifically. I'll be investigating this so stay tuned for further possible improvements (specifically for your architecture, I've been working on this problem a long time and know a few tricks I've picked up over the years for emulation).

You can tell this won't solve it though from the fact you're still seeing the bottlenecking and rubberbanding effects while pulling Docker images and other disk i/o intensive activities. This is a Pi problem in general and why I created the storage benchmark. It was exceptionally difficult to tell how people's storage performance was on the Pi until this benchmark (and tens of thousands of tests later) we actually have hard data on this and can make comparisons.

Definitely pibenchmarks.com will already have tests for your drive you can just search for as well. I think this will likely turn out to be a regular flash drive which are pretty slow (surprisingly so). Hopefully that helps as well!

Jeppe Hasseriis · Answer 25 · Tue May 24 2022 04:22:22 GMT+0800 (China Standard Time)

Running your benchmarking now. But I did some testing before and was getting horrible results! Write speed down to 2MB/s and Read speed down to 9MB/s. I really didn't realise the flash disk is this bad. :-(
This is the model https://pibenchmarks.com/brand/SanDisk_Cruzer_Fit

I'll definitely switch this one out as soon as possible.

Jeppe Hasseriis · Answer 26 · Tue May 24 2022 04:33:41 GMT+0800 (China Standard Time)

Category                  Test                      Result
HDParm                    Disk Read                 29.96 MB/s
HDParm                    Cached Disk Read          23.05 MB/s
DD                        Disk Write                1.8 MB/s
FIO                       4k random read            516 IOPS (2065 KB/s)
FIO                       4k random write           104 IOPS (416 KB/s)
IOZone                    4k read                   11607 KB/s
IOZone                    4k write                  1204 KB/s
IOZone                    4k random read            3353 KB/s
IOZone                    4k random write           738 KB/s

Score: 385

LOL! no wonder it feel slow

James A. Chambers · Answer 27 · Tue May 24 2022 05:26:24 GMT+0800 (China Standard Time)

Ahh yes, this was one of my misconceptions too before I made the storage benchmark. I knew it was a much lower grade of memory/storage they use in flash drives (compared to a SSD) but I had no idea it was roughly equivalent to a SD card and probably inferior to a A1 or A2 (application class) SD card (that literally is higher grade memory on a application class SD card than they use in these flash drives).

Good stuff, I really think that will alleviate your bottlenecking to take care of that first. I'll probably be doing some stuff with the container side over the next few weeks to see what I can do via emulation with box64 and that will help everyone on aarch64 but I think more of your issue right now is the storage. It might not even feel too bad with that taken care of even without my changes.

Thanks for testing it on there! We probably should make this a separate issue like you were alluding to as this is becoming a bit of a mess now but if you want to continue the conversation feel free to open one and we can keep this discussion in there for future reference / others to read!

My blog is probably great for this stuff too as that tends to just be more of what people need help with or the interesting topics going on at the moment. People frequently drop in and out too and I'm usually pretty fast to respond on there!

Diego-Rafael · Answer 28 · Wed May 25 2022 03:37:28 GMT+0800 (China Standard Time)

help; arm64, linux, ubuntu

James A. Chambers · Answer 29 · Wed May 25 2022 04:50:42 GMT+0800 (China Standard Time)

That's a permissions error. It needs to be ran as sudo (or you need to add your user to the docker group and configure the system so you don't need sudo) and it is not this issue.

Yours isn't even getting this far. Yours isn't even downloading the container because it says 'permission denied' which is why it says no such file or directory when it tries to run it. The container can't be downloaded since that's a privileged location and this user hasn't been set up to access sudoless docker.

Please open new issues going forward as I won't be responding further (I just said it was becoming a mess in here, there is no reason to put them in here like this thinking I'll just keep responding and I won't). When this different issue does happen and people search for it they are not going to find it since now it's wrapped up with this totally unrelated issue which is why we want to keep them separate as this is clearly not this.

Nothing personal but I should have cut it off there a long time ago because now it's actively hurting the project/documentation and people are just dropping everything into one thread apparently (and you weren't the first). Let's separate these out for everyone's sake!

恒 · Answer 30 · Sat Jan 20 2024 03:14:55 GMT+0800 (China Standard Time)

The server is running very slowly, and logging in takes a long time. My server is arm64 Equipment model CM311-1a-YST CPU amlogic Memory size 2 GB Flash memory size 16 GB

恒 · Answer 31 · Sat Jan 20 2024 03:19:34 GMT+0800 (China Standard Time)

CPU amlogic 1.9 GHz ， Cortex-A55， 4C/4T
Memory size 2 GB
Flash memory size 16 GB
It runs very slowly and takes 10 minutes to log in