Two Pi3b's upgraded today. The second was upgraded a few hours after the first to ensure good working order. Performed an update/upgrade/-up/reboot on each.
Prior uptimes were 132 & 155 days with numerous pihole -up in between with no problems.
Expected Behaviour:
Pihole should not quit unexpectedly.
Actual Behaviour:
Two separate piholes have both failed near simultaneously on two separate occurrences today; two hours apart.
FTL failed on one pihole per the service monitoring. The other did not appear to indicate FTL being down. Neither responded to DNS queries which lead to more 'panic than diagnosing further' (since kids and rarity of event leading me to be unprepared for a dual failure).
I performed a restartdns on both piholes. I also rebooted a single pihole, not both, at that time.
So far, both continue to operate as expected.
Are there any errors shown in /var/log/pihole-FTL.log or /var/log/syslog ?
I will look through this and report back anything significant.
You also have a lot of interfaces and active DHCP servers, on what appear to be different VLANs. Has any of that changed?
That they crash the very same second is suspicious. Probably the time of a specific query or a loop maxxed out or some network broadcast like RA. Do the query logs (and also FTL logs) show anything suspicions (or a large amount of queries) before the crash?
FTL itself crashes with a segmentation fault. To track down the backtrace I think we need @DL6ER.
where also some technical background is given. When you also check out my mail to the mailing list (link included over there), you'll see that this is very complex issue deep inside dnsmasq.
For now, you'd need to remove any custom IPv6 configuration like
server=/netflix.com/#
address=/netflix.com/::
etc. to avoid the crash from happening.
As soon as we have a bug fix available, I'll immediately set up a custom testing branch for FTL.
@Andy_Grant Just out of pure curiosity: Why do you want to block IPv6 traffic to Netflix? Is there a specific issue you are solving with this? I've seen such config lines multiple times by now (also to Spotify, etc.) from various users but I've never asked before.
Oof, removing that is unlikely to be an option. My ISP does not provide IPv6 connectivity so I have an HE tunnel. This was setup in 2018 or 2019. Netflix is highly allergic to VPN's and they apparently prefer IPv6 and think that I am using a VPN; blocking streams. By blocking IPv6 resolution, Netflix falls back to IPv4 and works.
Since rolling back a since pi to FTL v5.8.1, both have been running for 10 hours successfully. Will I want to roll back the other pi? Obviously usage was low overnight and Netflix was off.
Interesting option. This was deployed so long ago I don't think regex was an option back then. Or it was so new that deployment was low. Have many regex now, will give it a go after some further testing tonight when the Netflix crowd is awake.
The bug in dnsmasq is difficult to solve, hence, we decided to not suggest and submit a patch on our own as this might have been a few hours of work and, if the maintainers want to have it done differently in the end, it'd be wasted time. We're all awaiting a fix eagerly and I'll make a fixed FTL branch available as soon as possible.
Simon pushed a fix. He decided not to do the massive refurbishment but, instead, addressed the issue at hand with good faith that this was the only bug.
Roger that. Branch has been changed, will monitor and report. It crashed again last night so it won't take more than a day to know. Two days with certainty.
when we released the next version of Pi-hole that includes this fix or you'll stay forever on this version.
I'll try to remember coming back to this thread once we released the fix, however, you should better not bet on my memory...