Questions about dev image

[PromoFaux]

I actually said, or meant to say, if my meaning was unclear, is that due to time constraints I haven't gone through the above instructions for installing and setting up the debug tools yet. This is why I haven't included the gdb log. If I had the logs, I would have attached them to my comment – I certainly wouldn't leave them out on purpose and waste your time.

Related, Or Are Dev Images Just Really Unstable?

I'm not sure if you're suggesting that the dev image includes these tools, but I haven't found any like that on this Alpine image. It’s frustrating that the dev images of PiHole lack any symbols, backtracing, debug tools, or troubleshooting scripts. Also, right out of the box, the gravity db was corrupted or corrupted itself within the first hour without any block lists added the first day (error -2 on the homescreen). I had to follow some commands on a forum post to delete the DB and recreate it. The pihole repair commands did not work either. Just throwing it all out there. There isn’t even a way to restart the PiHole service/process without restarting the entire container, and the “reboot” command is missing as well – which I thought came standard with BusyBox. Many Docker containers have the reboot command.

I also completely understand that, naturally because these are dev images, there may be things broken, I'm not expecting it to be perfect, but where it already went through a beta testing phase I'm quite surprised by the number of issues I've encountered with PiHole right out within the first few days. That's actually the reason for my posts is to help share information about what I'm encountering, and hopefully these bugs can be fixed soon.

I’ll need to set aside some time tomorrow or the next to take down the Docker container and follow the above instructions for installing and configuring the debug features and tools. Unfortunately, I don't have that time at the moment. I can type at lightning speed tho, it's a talent of mine. If the information and logs I've provided aren't sufficient to pinpoint the problem, I'll try to get the debug environment set up this weekend.

Based on what I've found, you shouldn't have to go through much code. This issue occurs when the log entry "response is truncated" is written to the DNS log right after receiving notification from the DNS server that it's response to PiHole has been truncated. Presumably the DNS reply is too large for a udp packet. Wherever that event is handled, that's where the crash occurs. The code block handling the "response is truncated" event can't be more than 100 lines? Which even seems substantial for handing a DNS response and making 1 log entry. But perhaps I don't fully understand the complexity of PiHole’s event handling. Which leads me to

Reiterated: Consider adding backtracing, symbols, & debugging to PiHole Dev

Here is where I'd like to reiterate: Please consider including the debug tools, symbols, backtracing, etc., in the development branch builds of the Docker images or provide an easy way to enable debugging options. An option like “pihole-ftl --enable-debugging” that either enables backtracing, symbols, and tools, or fetches and sets them up, would be much preferable to manually downloading and installing them. Having to take down the container to add permissions and commands and then rebuild it makes me nervous, as I risk losing everything in it. Taking down or editing containers has sometimes taken me whole days, or even multiple days when things have gone wrong, and in the past I've lo losing everything I set up. Since then I learned you can save images of your changes   I admit that while I am very technically inclined with over a decade of software repair experience, Docker is very new to me still, so my understanding and handling of it may not be optimal. 

Reiterated: My Plea, Please Consider Bringing Back Update Command to PiHole Docker Images

Finally, I'm going to reiterate my stance and plea here. Please hear me out. The decision to disable the update functionality in the PiHole-FTL, just because it's Docker and re-pulling an image is the Docker way – this method of updating PiHole is incredibly frustrating. That works for some things, but that doesn't have to be “the way.” Reconfiguring, reinstalling, and setting up my environment again is a significant time investment. For eg. on PiHole I have many tools and scripts I install, eg. ssh, network and IP troubleshooting tools, Cloudflared, dnscrypt, log rules automation. All that in addition to custom scripts for things such as IPv6 static addresses and static routes. I have my own /48 static block of IPv6 from my ISP, but it's not SLAAC compatible, I have to setup the routes myself, and Docker doesn't support that.

I know some might argue that a Docker container should only contain PiHole, but that's not practical. Even your official docs describe  installing and setting up cloudflared, which isn't included in the images. Enabling the update functionality would save users considerable time, effort, and frustration. If you must, then you could put the update feature in Docker images behind a disclaimer or labs option, but that would certainly be far better than the current option of having to tear down the container.

Request for Feedback Reply

I hope the PiHole devs take the time to fully read my comments and feedback, and consider my opinions / suggestions. Let me know if you need me to provide any additional information about my feedback / suggestions. If you could, I would like whoever is in charge of these decisions to answer for me if there is any specific reasons these actually can't/won't be done, that would be helpful to me. 

I will still setup the debugging tools, hopefully, this weekend, if the provided error information and logs isn't sufficient to find the bug.* However, as of right now PiHole Dev image is not usable. It crashes far too much 30+ times a day, sometimes within 20 min of pulling the Docker image. This is build Dec 22 2024. I'm surprised it's working for anyone else, but perhaps it has to do with using Cloudflared as the DNS provider. Maybe the way Cloudflared is providing it's responses, but a DNS response packet doesn't change drastically from one server to the next, so that doesn't make a lot of sense either.

Originally posted by @MNLierman in #2112

[PromoFaux]

Reiterated: My Plea, Please Consider Bringing Back Update Command to PiHole Docker Images

Docker containers are largely designed to be immutable, meaning that once a container is built and deployed, its filesystem should not change during runtime. This immutability ensures consistency, reliability, and security across different environments. By treating containers as immutable, any updates or changes are implemented by building and deploying new container images, rather than modifying existing running containers.

Of course while the filesystem inside a container should remain immutable, Docker provides mechanisms to handle dynamic or persistent data without violating the principles of immutability - for example using host mounts (volumes/bind mounts) or environment variables. The Docker section of the docs for Pi-hole v6 have been expanded (https://deploy-preview-338--pihole-docs.netlify.app/docker/)

I know some might argue that a Docker container should only contain PiHole, but that's not practical. Even your official docs describe installing and setting up cloudflared, which isn't included in the images.

These guides are meant for installing cloudfared alongside Pi-hole in a bare metal installation. The Pi-hole docker container should only contain Pi-hole, which is "the docker way" (one service per container). But even this is not a blocker - simply create a secondary container to house your cloudfared installation so that it is not destroyed every time you pull and recreate the Pi-hole container. Here is quite an old guide, aimed at v5, but the overall principles should remain similar: https://mroach.com/2020/08/pi-hole-and-cloudflared-with-docker/

All that in addition to custom scripts for things such as IPv6 static addresses and static routes.

What custom scripts are you including?

However, as of right now PiHole Dev image is not usable. It crashes far too much 30+ times a day, sometimes within 20 min of pulling the Docker image.

I would suggest that it is perhaps due to configuration more than anything here - I've not seen any other reports of such drastic crashes, nor is my own deployment crashing :)

[MNLierman]

It has nothing to do with the configuration or what I've installed. I had a feeling someone was going to say that. It happens on a brand new fresh downloaded Dev image of pie hole. It instantly started crashing as soon as I set it up, and the gravity database was corrupted within the first few minutes if not within the first hour. That never worked, I had to follow commands in order to reset it. No it has nothing to do with the configuration. Right now everything is removed and it's still doing it. It's doing it on a fresh pull of the dev image.

Outlined what I believe is happening, pie hole is incorrectly handling large UDP response packets from cloudflare. This is a bug, it doesn't do it in version 5, it only does it in version 6.

In that thread, there's a lot of people that had drastic crashing every hour. And all over Google you can find the same exact error since 2020. It's almost impossible to find anything relevant to my specific error because I know that those error reports from 2020 that share the exact same message to the letter can't possibly be 100% related to my issue. So this is some kind of generic memory error because of the way pie hole handles memory. I would definitely suggest a different way of error handling. My other suggestions also still hold significant ground. The death images should have full symbols and everything else enabled so that those crashes will actually have a bit of a stack Trace showing where it's coming from and what's happening.

(Will spell check later, using voice type.)

[PromoFaux]

OK, well this thread was split out to respond to your more docker-specific questions - not to dismiss any potential bug in FTL - That may still exist, and you are more than welcome to discuss this on the original thread :)