FTL crash after update v4.3.1

Problem with Beta 5.0:
I've been using Beta 5.0 for awhile w/o problems. I did a pihole -up yesterday. Ran into some problems during the upgrade and decided to do a clean install of the latest Raspian and pihole v4.* and upgrade to beta v5.0

The FTL service is crashing and seems to take the DNS service with it. I've restarted the dns service but FTL crashes soon after along with dns service.

Seems to be related to using pihole dhcp server and having advanced dhcp ipv6 support (SLAAC + RA) checked, but not sure. I haven't been able to do much testing as other people are home and I need to keep the internet up so my router isn't pointing to pihole right now.

The error is a Segmentation fault at address: 0x2 with code: SEGV_MAPERR (Address not mapped to object)

Debug Token:
fx7xul9txq
and
u6fw7rijc2

Edit: adding system info

Pi 3 Model B+ rev 1.3 using ethernet connection
TP-Link Archer AC3150 router V1
Arris SB6190 cable modem
Xfinity 200mbps service.
Raspbian Buster with desktop and recommended software Feb 2020.
Only SSH enabled and xrdp installed. Wifi not setup.

/pi# pihole -v
Pi-hole version is v4.3.5-459-g0fad979 (Latest: v4.4)
AdminLTE version is v4.3.2-439-g6fdeee5 (Latest: v4.3.3)
FTL version is vDev-b6364d0 (Latest: v4.3.1)

/pi# uname -a
Linux raspberrypi 4.19.97-v7+ #1294 SMP Thu Jan 30 13:15:58 GMT 2020 armv7l GNU/Linux

2 Likes

Same problem here. Restarting the Pi does not help.

The Admin portal is online and shows "Lost connection to API" with 2 red balls:

  • DNS service not running
  • FTL offline

After i run "sudo systemctl restart pihole-FTL" the admin portal is back working for maximum 60seconds, then it shows the message again with the same status of DNS and FTL.

I've timed the time it's up and goes down, after about 40sec it goes down.

debug token: murbfxc6e8

Doing "reconfigure" and uncheck ipv6 does not help.

Same issue here

Token: https://tricorder.pi-hole.net/k5wmqxam2v

I'm seeing a similar issue. My pihole ran an update command at midnight (pihole -up). Now, the DNS keeps crashing. pihole restartdns will fix it for a few minutes, but then it just crashes again.

It is somewhat random at quite how long it lasts. Here is a log:

[2020-03-30 16:30:00.366 8977] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[2020-03-30 16:30:00.366 8977] ---------------------------->  FTL crashed!  <----------------------------
[2020-03-30 16:30:00.366 8977] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[2020-03-30 16:30:00.366 8977] Please report a bug at https://github.com/pi-hole/FTL/issues
[2020-03-30 16:30:00.366 8977] and include in your report already the following details:
[2020-03-30 16:30:00.366 8977] FTL has been running for 88 seconds
[2020-03-30 16:30:00.366 8977] FTL branch: release/v5.0
[2020-03-30 16:30:00.366 8977] FTL version: vDev-b6364d0
[2020-03-30 16:30:00.366 8977] FTL commit: b6364d0
[2020-03-30 16:30:00.366 8977] FTL date: 2020-03-29 23:23:02 +0200
[2020-03-30 16:30:00.367 8977] FTL user: started as pihole, ended as pihole
[2020-03-30 16:30:00.367 8977] Compiled for armhf (compiled on CI) using arm-linux-gnueabihf-gcc (Debian 6.3.0-18) 6.3.0 20170516
[2020-03-30 16:30:00.367 8977] Received signal: Segmentation fault
[2020-03-30 16:30:00.367 8977]      at address: 0x1
[2020-03-30 16:30:00.367 8977]      with code: SEGV_MAPERR (Address not mapped to object)
[2020-03-30 16:30:00.367 8977] Backtrace:
[2020-03-30 16:30:00.368 8977] B[0000]: 0x442618, /usr/bin/pihole-FTL(+0x23618) [0x442618]
[2020-03-30 16:30:00.368 8977] B[0001]: 0x76da9130, /lib/arm-linux-gnueabihf/libc.so.6(__default_rt_sa_restorer+0) [0x76da9130]
[2020-03-30 16:30:00.368 8977] ------ Listing content of directory /dev/shm ------
[2020-03-30 16:30:00.368 8977] File Mode User:Group  Filesize Filename
[2020-03-30 16:30:00.368 8977] rwxrwxrwx root:root 260 .
[2020-03-30 16:30:00.368 8977] rwxr-xr-x root:root 4K ..
[2020-03-30 16:30:00.369 8977] rw------- pihole:pihole 4K FTL-per-client-regex
[2020-03-30 16:30:00.369 8977] rw------- pihole:pihole 4K FTL-dns-cache
[2020-03-30 16:30:00.370 8977] rw------- pihole:pihole 29K FTL-overTime
[2020-03-30 16:30:00.370 8977] rw------- pihole:pihole 17M FTL-queries
[2020-03-30 16:30:00.370 8977] rw------- pihole:pihole 20K FTL-upstreams
[2020-03-30 16:30:00.371 8977] rw------- pihole:pihole 102K FTL-clients
[2020-03-30 16:30:00.371 8977] rw------- pihole:pihole 66K FTL-domains
[2020-03-30 16:30:00.372 8977] rw------- pihole:pihole 115K FTL-strings
[2020-03-30 16:30:00.372 8977] rw------- pihole:pihole 12 FTL-settings
[2020-03-30 16:30:00.373 8977] rw------- pihole:pihole 124 FTL-counters
[2020-03-30 16:30:00.373 8977] rw------- pihole:pihole 28 FTL-lock
[2020-03-30 16:30:00.373 8977] ---------------------------------------------------
[2020-03-30 16:30:00.373 8977] Thank you for helping us to improve our FTL engine!
[2020-03-30 16:30:00.373 8977] FTL terminated!

What hardware are you guys using?

I have updated to vDev-b6364d0 on two pi-holes I am using without any untoward effect.
Using it on RPi 3B+

I have two piholes running.

pi@pihole:~ $ grep Revision /proc/cpuinfo
Revision	: a22082

Which is Model 3B (Q1 2016)

pi@pihole2:~ $ grep Revision /proc/cpuinfo
Revision	: a01041

Which is Model 2B (Q1 2015)

The 2B seems to be crashing less, but it is also in the second position on my DNS settings, so it gets much less queries.

Edit: Some more details:

Pi-hole Version vDev (release/v5.0, v4.3.5-452-g0fad9792)
Web Interface Version vDev (release/v5.0, v4.3.2-439-g6fdeee53)
FTL Version vDev (release/v5.0, vDev-b6364d0)

pi@pihole:~ $ uname -a
Linux pihole 4.19.108-v7+ #1298 SMP Fri Mar 6 18:04:35 GMT 2020 armv7l GNU/Linux

I'm on a Model 3B+ Rev 1.3 using ethernet connection.

Edit: I added more system info in my 1st post.

@ubenmackin & @bigpcjunky
Here is what I show

Pi-hole version is v4.3.5-452-g0fad9792 (Latest: v4.4)
AdminLTE version is v4.3.2-439-g6fdeee53 (Latest: v4.3.3)
FTL version is vDev-b6364d0 (Latest: v4.3.1)

uname -a
Linux PiHole 4.19.97-v7+ #1294 SMP Thu Jan 30 13:15:58 GMT 2020 armv7l GNU/Linux

/prof/cpuinfo
Revision : a020d3

Model BCM2835 - Pi 3 Model B+|
Version a020d3 - Rev. 1.3

Edit - Using Ethernet connection

I guess we will have to wait for one of the developers to shed light on why 2 3B+ works while 1 doesn’t

Same issue here but with a Pi 4, keeps crashing continuously:

[2020-03-31 02:42:00.180 991] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[2020-03-31 02:42:00.180 991] ---------------------------->  FTL crashed!  <----------------------------
[2020-03-31 02:42:00.180 991] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[2020-03-31 02:42:00.180 991] Please report a bug at https://github.com/pi-hole/FTL/issues
[2020-03-31 02:42:00.180 991] and include in your report already the following details:
[2020-03-31 02:42:00.180 991] FTL has been running for 25 seconds
[2020-03-31 02:42:00.180 991] FTL branch: release/v5.0
[2020-03-31 02:42:00.180 991] FTL version: vDev-b6364d0
[2020-03-31 02:42:00.180 991] FTL commit: b6364d0
[2020-03-31 02:42:00.180 991] FTL date: 2020-03-29 23:23:02 +0200
[2020-03-31 02:42:00.180 991] FTL user: started as pihole, ended as pihole
[2020-03-31 02:42:00.180 991] Compiled for armhf (compiled on CI) using arm-linux-gnueabihf-gcc (Debian 6.3.0-18) 6.3.0 20170516
[2020-03-31 02:42:00.181 991] Received signal: Segmentation fault
[2020-03-31 02:42:00.181 991]      at address: 0xb6cea9ec
[2020-03-31 02:42:00.181 991]      with code: SEGV_MAPERR (Address not mapped to object)
[2020-03-31 02:42:00.181 991] Backtrace:
[2020-03-31 02:42:00.181 991] B[0000]: 0x51c618, /usr/bin/pihole-FTL(+0x23618) [0x51c618]
[2020-03-31 02:42:00.181 991] B[0001]: 0xb6d4d130, /lib/arm-linux-gnueabihf/libc.so.6(__default_rt_sa_restorer+0) [0xb6d4d130]
[2020-03-31 02:42:00.181 991] B[0002]: 0x521b50, /usr/bin/pihole-FTL(resolveClients+0xb7) [0x521b50]
[2020-03-31 02:42:00.181 991] B[0003]: 0x521d7e, /usr/bin/pihole-FTL(DNSclient_thread+0x85) [0x521d7e]
[2020-03-31 02:42:00.181 991] ------ Listing content of directory /dev/shm ------
[2020-03-31 02:42:00.182 991] File Mode User:Group  Filesize Filename
[2020-03-31 02:42:00.182 991] rwxrwxrwx root:root 260 .
[2020-03-31 02:42:00.182 991] rwxr-xr-x root:root 4K ..
[2020-03-31 02:42:00.182 991] rw------- pihole:pihole 4K FTL-per-client-regex
[2020-03-31 02:42:00.182 991] rw------- pihole:pihole 4K FTL-dns-cache
[2020-03-31 02:42:00.183 991] rw------- pihole:pihole 29K FTL-overTime
[2020-03-31 02:42:00.183 991] rw------- pihole:pihole 18M FTL-queries
[2020-03-31 02:42:00.183 991] rw------- pihole:pihole 20K FTL-upstreams
[2020-03-31 02:42:00.183 991] rw------- pihole:pihole 41K FTL-clients
[2020-03-31 02:42:00.183 991] rw------- pihole:pihole 66K FTL-domains
[2020-03-31 02:42:00.184 991] rw------- pihole:pihole 45K FTL-strings
[2020-03-31 02:42:00.184 991] rw------- pihole:pihole 12 FTL-settings
[2020-03-31 02:42:00.184 991] rw------- pihole:pihole 124 FTL-counters
[2020-03-31 02:42:00.184 991] rw------- pihole:pihole 28 FTL-lock
[2020-03-31 02:42:00.184 991] ---------------------------------------------------
[2020-03-31 02:42:00.184 991] Thank you for helping us to improve our FTL engine!
[2020-03-31 02:42:00.184 991] FTL terminated!

Same issue here. Ran pihole -up and FTL keeps crashing. I had to switch my routers DHCP back on til this gets resolved.

In your debug log:

2020-03-30 22:42:04: (mod_fastcgi.c.421) FastCGI-stderr: PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 14684160 bytes) in /var/www/html/admin/api_db.php on line 404

Do others have the same error in their debug logs?

2 Piholes here (3b & 4 both Buster fully uptodate) - both had FTL crashing after this mornings Pihole -up.

Pi 4 working after a single reboot. Pi 3b needed 2 reboots

-----tail of pihole-FTL.log------
[2020-03-31 11:18:00.180 4668] ----------------------------> FTL crashed! <----------------------------
[2020-03-31 11:18:00.180 4668] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[2020-03-31 11:18:00.180 4668] Please report a bug at Issues · pi-hole/FTL · GitHub
[2020-03-31 11:18:00.180 4668] and include in your report already the following details:
[2020-03-31 11:18:00.180 4668] FTL has been running for 59 seconds
[2020-03-31 11:18:00.180 4668] FTL branch: release/v5.0
[2020-03-31 11:18:00.180 4668] FTL version: vDev-b6364d0
[2020-03-31 11:18:00.180 4668] FTL commit: b6364d0
[2020-03-31 11:18:00.180 4668] FTL date: 2020-03-29 23:23:02 +0200
[2020-03-31 11:18:00.181 4668] FTL user: started as pihole, ended as pihole
[2020-03-31 11:18:00.181 4668] Compiled for armhf (compiled on CI) using arm-linux-gnueabihf-gcc (Debian 6.3.0-18) 6.3.0 20170516
[2020-03-31 11:18:00.181 4668] Received signal: Segmentation fault
[2020-03-31 11:18:00.181 4668] at address: 0x1
[2020-03-31 11:18:00.181 4668] with code: SEGV_MAPERR (Address not mapped to object)
[2020-03-31 11:18:00.181 4668] Backtrace:
[2020-03-31 11:18:00.181 4668] B[0000]: 0x499618, /usr/bin/pihole-FTL(+0x23618) [0x499618]
[2020-03-31 11:18:00.181 4668] B[0001]: 0xb6d77130, /lib/arm-linux-gnueabihf/libc.so.6(__default_rt_sa_restorer+0) [0xb6d77130]
[2020-03-31 11:18:00.182 4668] ------ Listing content of directory /dev/shm ------
[2020-03-31 11:18:00.182 4668] File Mode User:Group Filesize Filename
[2020-03-31 11:18:00.182 4668] rwxrwxrwx root:root 260 .
[2020-03-31 11:18:00.182 4668] rwxr-xr-x root:root 4K ..
[2020-03-31 11:18:00.182 4668] rw------- pihole:pihole 4K FTL-per-client-regex
[2020-03-31 11:18:00.182 4668] rw------- pihole:pihole 4K FTL-dns-cache
[2020-03-31 11:18:00.183 4668] rw------- pihole:pihole 29K FTL-overTime
[2020-03-31 11:18:00.183 4668] rw------- pihole:pihole 1M FTL-queries
[2020-03-31 11:18:00.183 4668] rw------- pihole:pihole 20K FTL-upstreams
[2020-03-31 11:18:00.183 4668] rw------- pihole:pihole 20K FTL-clients
[2020-03-31 11:18:00.184 4668] rw------- pihole:pihole 66K FTL-domains
[2020-03-31 11:18:00.184 4668] rw------- pihole:pihole 29K FTL-strings
[2020-03-31 11:18:00.184 4668] rw------- pihole:pihole 12 FTL-settings
[2020-03-31 11:18:00.184 4668] rw------- pihole:pihole 124 FTL-counters
[2020-03-31 11:18:00.184 4668] rw------- pihole:pihole 28 FTL-lock
[2020-03-31 11:18:00.184 4668] ---------------------------------------------------
[2020-03-31 11:18:00.185 4668] Thank you for helping us to improve our FTL engine!
[2020-03-31 11:18:00.185 4668] FTL terminated!

Same issue here, debug code dhwwvvkgd8

Seems ipV6 addresses are not the same

I posted something similar in the following thread :

see if setting MAXDBDAYS to 0 help to fix the problem temporarily.

2 hours later I made the mistake of rebooting my Pi 3b - unable to get it working again with multiple reboots.
Same error
[2020-03-31 13:35:00.261 601] Received signal: Segmentation fault
[2020-03-31 13:35:00.262 601] at address: 0x1
[2020-03-31 13:35:00.262 601] with code: SEGV_MAPERR (Address not mapped to object)
[2020-03-31 13:35:00.262 601] Backtrace:
[2020-03-31 13:35:00.262 601] B[0000]: 0x43c618, /usr/bin/pihole-FTL(+0x23618) [0x43c618]
[2020-03-31 13:35:00.263 601] B[0001]: 0x76d7f130, /lib/arm-linux-gnueabihf/libc.so.6(__default_rt_sa_restorer+0) [0x76d7f130]
[2020-03-31 13:35:00.263 601] B[0002]: 0x434c1c, /usr/bin/pihole-FTL(parse_neighbor_cache+0x343) [0x434c1c]
[2020-03-31 13:35:00.263 601] B[0003]: 0x4375e8, /usr/bin/pihole-FTL(DB_thread+0xc7) [0x4375e8]

Thank you! I had just installed pihole on an atomic pi and could not get it stay up for more than 1 minute. So far so good since setting MAXDBDAYS=0.

Works for me too (FTL is not stopping anymore), but no graphs in the web interface as a result...

Thanks for your reports, we're currently trying to isolate the cause of the issue. It is interesting you note that the crash disappears when disabling the database. Please try again with the database enabled after updating your Pi-holes to the latest version of the beta (we just pushed a modification to the database code). I do not really expect this to resolve this bug but one never knows.

Now we know.