"Latest" Image Restarting (132) Issue

[KilometerM]

Hello,

First of all, thank you for the great image. I hadn't updated to the latest image for quite awhile and decided to do that today. I run this image on two Raspberry Pis. On the first Pi, a Raspberry Pi 2, I ran docker pull klutchell/dnscrypt-proxy which pulled the latest image, removed the old container, and executed my docker run command. Everything went good and I was up and running successfully on version 2.1.5.

On the second Pi, a Raspberry Pi Zero, I went through the same process, but this time the container running on the latest image constantly restarts. The status when running docker ps -a shows statuses such as Restarting (132) 7 seconds ago. I also tried specifically pulling the linux/arm/v6 image by its sha256 hash, in case the wrong architecture was being pulled, but the result was the same. Reverting back to the prior image of version 2.1.4 runs without issue and is what I've been running for months.

Any thoughts on what changed between the last two images that would cause the latest to no longer successfully run on the Pi Zero? Any way I could help troubleshoot this? Since it runs fine on the Pi 2, but not the Zero that leads me to believe it may be related to the Pi Zero's linux/arm/v6 architecture.

Thanks again!

[klutchell]

Hey @KilometerM , let's see if we can't figure out why the container isn't starting.

First off, here's the changelog between those releases for our reference. A lot of commits but very little related to the contents of the image.

v2.1.4...v2.1.5

We added a dnsprobe binary for use in healthchecks, but I assume you haven't configured any healthchecks? Can you provide your run command? Do you get any logs from the container if you run it in the foreground (without -d)?

I also see that we are passing the armv6 self-tests. Not sure if you have access to these or not but the logs are here:
https://github.com/klutchell/dnscrypt-proxy-docker/actions/runs/7633466685/job/20795773105

I would also suggest we try running the container once, and then perform a docker inspect on the container to see it it provides an exit code, or stderr message, or something to indicate the reason for failure.

I'll try to make some time to test the image myself on an RPI Zero but it would be better if I had your exact run command. What OS are you using on your RPI Zero?

[KilometerM]

Hi @klutchell, thanks for the response. I have not configured any healthchecks. My run command is as follows:

docker run -d --restart=unless-stopped \
--name dnscrypt-proxy \
-p 53:5053/tcp -p 53:5053/udp \
-v "/home/pi/dockervol/dnscrypt:/config" \
-v "/etc/localtime:/etc/localtime:ro" \
klutchell/dnscrypt-proxy

I have also run the above command with the volume lines removed in case it was something in my config that was causing the issue, but the results were the same with the container constantly restarting. This is also the same command I use on the RPi 2 where the container starts and runs successfully.

Unfortunately, I do not get any logs when running it in the foreground without -d. After a few seconds the container just exits without any logs and I'm returned to a new prompt.

I ran docker inspect on the container. I believe this is the potentially relevant portion, but if there's another field you're interested in, let me know and I'd be happy to pass that along:

"State": { "Status": "exited", "Running": false, "Paused": false, "Restarting": false, "OOMKilled": false, "Dead": false, "Pid": 0, "ExitCode": 132, "Error": "", "StartedAt": "2024-01-25T23:00:49.015509333Z", "FinishedAt": "2024-01-25T23:00:48.995475432Z" },

I actually imaged a new microsd card in case something was wrong with my previous installation, but even with a clean image and only docker installed the result I'm seeing is the same. The current OS I am running is the latest Raspberry Pi OS Lite 32-bit bookworm image: 2023-12-11-raspios-bookworm-armhf-lite.img.xz.

[klutchell]

I reproduced it on my device, and it does not appear to be OS specific, and it was only introduced in 2.1.5 as you said.

I'll let you know when I figure out more. Thanks for raising this issue!

[klutchell]

It works when rolling back golang to 1.20 from 1.21, so maybe this is an upstream bug or deprecation?

See this and this.

Looking into the proper solution without rolling back.

[KilometerM]

Thanks for your work running this down!

[klutchell]

Can you try again with the main tag? I don't like to move existing tags to new commits like 2.1.5 but I might make an exception in this case.

[KilometerM]

I pulled main tag and tested. From my short test everything seems to be working correctly. Let me know if there's anything else I can help with. Thanks again!

[klutchell]

Will using the main tag work for you until the next upstream release? If anyone else encounters the issue I will suggest they do the same to get the armv6 fix.

[KilometerM]

Yes, that's not a problem for me. I'll plan on doing that until the next upstream release.