Pihole 6.0 beta and SQLite issue

TheBossME · August 5, 2024, 6:59am

Hi, I have daily issue with SQLite database and pihole v6. Pihole becomes non responsible. I tested repairing and recreation without success. Issue comes back. I have this behavior since 1 week.
Increasing memory to 8GB of the Debian LXC container on Proxmox 8.2.4 do not help. I store only 24 hours of client activity.

Does somebody see same issue like me with similar or same setup ?. I will go forward and recreate the LXC container or install pihole v6 development Version into a VM. Proxmox is on 6.8.8.4 kernel. Pihole will automatically updated daily via cronjob.

Bucking_Horn · August 5, 2024, 11:10am

What does that update job look like?

TheBossME · August 5, 2024, 11:30am

0 3,9,15,21 * * * /usr/local/bin/pihole -up

I‘ve run now pihole for testing purposes in Debian bookworm VM.
I‘ve copied the pihole.toml and gravity.db from the LXC

buntspexxt · August 5, 2024, 5:15pm

Is it really necessary to run this cronjob 4 times per day?

Personally i manually run pihole -up on the weekend.

TheBossME · August 5, 2024, 5:36pm

Does a change from 4 times per day to 1 time per week help to solve the issue ?

buntspexxt · August 5, 2024, 6:15pm

Run it manually. This script is something i would not run in cron.

DL6ER · August 5, 2024, 7:51pm

Please provide the last couple of lines from /var/log/pihole/FTL.log once this happens so we can start looking at what might be causing this.

TheBossME · August 6, 2024, 3:18am

2024-08-06 01:00:00.650 CEST [467/T474] WARNING: Host name of client "192.168.x.x" => "Meross Smart Switch.domain" contains (at least) one invalid character (hex 20) at position 6
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO: ---------------------------->  FTL crashed!  <----------------------------
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO: Please report a bug at https://github.com/pi-hole/FTL/issues
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO: and include in your report already the following details:
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO: FTL has been running for 2 seconds
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO: FTL branch: development-v6
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO: FTL version: vDev-cce2c21
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO: FTL commit: cce2c210
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO: FTL date: 2024-08-04 14:47:39 +0200
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO: FTL user: started as pihole, ended as pihole
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO: Compiled for linux/amd64 (compiled on CI) using cc (Alpine 13.2.1_git20240309) 13.2.1 20240309
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO: Process details: MID: 2388
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO:                  PID: 2388
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO:                  TID: 2391
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO:                  Name: dns-client
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO: Received signal: Segmentation fault
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO:      at address: 0x6e6961006410
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO:      with code:  SEGV_MAPERR (Address not mapped to object)
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO: !!! INFO: pihole-FTL has not been compiled with glibc/backtrace support, not generating one !!!
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO: ------ Listing content of directory /dev/shm ------
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO: File Mode User:Group      Size  Filename
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO: rwxrwxrwx root:root       280   .
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO: rwxr-xr-x root:root         3K  ..
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO: rw------- pihole:pihole   569K  FTL-fifo-log
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO: rw------- pihole:pihole     8K  FTL-per-client-regex
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO: rw------- pihole:pihole    98K  FTL-dns-cache
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO: rw------- pihole:pihole     8K  FTL-overTime
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO: rw------- pihole:pihole     1M  FTL-queries
2024-08-06 01:00:48.416 CEST [2388/T2391] INFO: rw------- pihole:pihole    29K  FTL-upstreams
2024-08-06 01:00:48.417 CEST [2388/T2391] INFO: rw------- pihole:pihole    86K  FTL-clients
2024-08-06 01:00:48.417 CEST [2388/T2391] INFO: rw------- pihole:pihole    41K  FTL-domains
2024-08-06 01:00:48.417 CEST [2388/T2391] INFO: rw------- pihole:pihole    82K  FTL-strings
2024-08-06 01:00:48.417 CEST [2388/T2391] INFO: rw------- pihole:pihole    16   FTL-settings
2024-08-06 01:00:48.417 CEST [2388/T2391] INFO: rw------- pihole:pihole   292   FTL-counters
2024-08-06 01:00:48.417 CEST [2388/T2391] INFO: rw------- pihole:pihole    88   FTL-lock
2024-08-06 01:00:48.417 CEST [2388/T2391] INFO: ---------------------------------------------------
2024-08-06 01:00:48.417 CEST [2388/T2391] INFO: Please also include some lines from above the !!!!!!!!! header.
2024-08-06 01:00:48.417 CEST [2388/T2391] INFO: Thank you for helping us to improve our FTL engine!

TheBossME · August 6, 2024, 3:30am

It looks like the issue is initiated by a meross device on the network while sending „blanks“ in the hostname. pihole cannot handle this actually and crashes. I saw this blank hostname problem in the past from other users too. The hostname is not the one reported by pihole. This is also defined and reserved hostname in the dhcp server (not pihole dhcp) without any blanks.

DL6ER · August 6, 2024, 6:57pm

I don't think the host name is the cause. If we look closely at the logs, we see that the crash happens almost one minute later in a different process. It seems you have two instances of pihole-FTL running at the same time (PIDs 467 and 2388) which is indeed unsupported.

Your posted log excerpt leaves a few question-marks behind - is it really complete? Please post some more lines, also into the past when this happens next time including some of the lines from FTL.log.1 in case this happened at the very top of FTL.log.

This PR will improve on concurrency between running pihole-FTL processes and - in theory - allow it (but at the same time tries hard to prevent this from happening):

github.com/pi-hole/FTL

Improve pihole-FTL process concurrency

pi-hole:development-v6 ← pi-hole:tweak/multi-FTL

opened 04:44PM - 06 Aug 24 UTC

DL6ER

+79 -93

# What does this implement/fix? FTL is trying hard to prevent you from starti…ng another instance of itself. It does so by creating a PID file in `/run/pihole-FTL.pid` and checking for its existence. If the file is present, FTL assumes that another instance is already running and exits. It also checks for the existence of the shared memory objects `/dev/shm/FTL-*` and exits if they are present. These checks can be fooled by manually removing the PID file or shared memory objects (needs `root` privileges). This can lead to multiple instances of FTL running at the same time, which can cause various issues. The most commonly seen issue is that, when the first process needs more memory, its original shared memory objects are already gone. Hence, it actually tries to resize the shared memory objects of the second instance which, on the other hand, doesn't expect this and crashes. As the first process was not able to allocate more memory, this process will eventually crash as well. This commit resolves this by: 1. **Improve support for concurrent `pihole-FTL` instances** Even when this continues to be somewhat discouraged, it is now possible to run multiple instances of `pihole-FTL` at the same time. This is achieved by ensuring that we keep the shared memory object file descriptors open as long as the process is running. This way, the shared memory objects are not removed until the process exits. This also means that the shared memory objects are not *hard* removed when they are deleted from the outside of the process (in Linux, a file continues to exist as long as there is at least one open file descriptor pointing to it). A hypothetical second instance of `pihole-FTL` will now be able to create new shared memory objects without interfering with the first instance. This is a more robust solution than the previous one, as it doesn't rely on the existence of the PID file or shared memory objects which might have been removed by external influences. 3. **Check for a potential second instance earlier in the code** We move the check to before even trying to create shared memory objects. This way, we can exit early if we detect that another instance is already running. This is a more efficient solution than the previous one, as we don't need to create shared memory objects just to find out that we can't use them. 5. **Add an exclusive lock on the shared memory objects** Even when this is not strictly necessary, it is a good practice to prevent other processes from interfering with the shared memory objects. This is especially important on systems which isolate processes from each other and is a safety net in rare cases such as multiple Docker containers (isolating processes from one another by default) with (incorrectly!) host-mounted shared memory folders. Once they remove the mounting of `dev/shm`, they will again be able to run multiple `pihole-FTL` across multiple containers. **Related issue or feature (if applicable):** N/A **Pull request in [docs](https://github.com/pi-hole/docs) with documentation (if applicable):** N/A --- **By submitting this pull request, I confirm the following:** 1. I have read and understood the [contributors guide](https://docs.pi-hole.net/guides/github/contributing/), as well as this entire template. I understand which branch to base my commits and Pull Requests against. 3. I have commented my proposed changes within the code. 4. I am willing to help maintain this change if there are issues with it later. 7. It is compatible with the [EUPL 1.2 license](https://opensource.org/licenses/EUPL-1.1) 8. I have squashed any insignificant commits. ([`git rebase`](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html)) ## Checklist: - [x] The code change is tested and works locally. - [x] I based my code and PRs against the repositories `developmental` branch. - [x] I [signed off](https://docs.pi-hole.net/guides/github/how-to-signoff/) all commits. Pi-hole enforces the [DCO](https://docs.pi-hole.net/guides/github/dco/) for all contributions - [x] I [signed](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) all my commits. Pi-hole requires signatures to verify authorship - [x] I have read the above and my PR is ready for review.

TheBossME · August 7, 2024, 10:42am

No, there are no 2 instances installed. I copied from different locations in the log file.

Additionally I‘ve told you, that I recreated a second pihole instance in a VM. I have copied the database files from the failed instance directly.

After opening the issue report I do the following:

make a backup of the config files Via the web interface
Delete all database files and reconfigure from scratch
using Pihole -r

After clearing the database and creating a new one I do import the prior backed up config files.

pihole -g to create my gravity.db with my old content.

This is done more than 24 hour ago and pihole didn‘t crashed since then.
Also no message in diagnostic do appear that a „meross smart hub“

If I haven’t the issue again please close this as solved in 2 days from now.
Thank you.

TheBossME · August 9, 2024, 6:12am

2024-08-09 00:10:00.027 CEST [199/T201] INFO: Size of /etc/pihole/pihole-FTL.db is 3.07 MB, deleted 388 rows
2024-08-09 00:20:00.087 CEST [199/T201] INFO: Size of /etc/pihole/pihole-FTL.db is 3.07 MB, deleted 385 rows
2024-08-09 00:30:00.086 CEST [199/T201] INFO: Size of /etc/pihole/pihole-FTL.db is 3.07 MB, deleted 383 rows
2024-08-09 00:40:00.055 CEST [199/T201] INFO: Size of /etc/pihole/pihole-FTL.db is 3.07 MB, deleted 381 rows
2024-08-09 00:50:00.093 CEST [199/T201] INFO: Size of /etc/pihole/pihole-FTL.db is 3.07 MB, deleted 379 rows
2024-08-09 00:59:00.023 CEST [199/T201] INFO: Size of /etc/pihole/pihole-FTL.db is 3.07 MB, deleted 376 rows
2024-08-09 01:00:00.632 CEST [199/T203] WARNING: Host name of client "192.168.27.76" => "Meross Smart Switch.fritz.box" contains (at least) o
ne invalid character (hex 20) at position 6
2024-08-09 01:00:00.632 CEST [199/T203] INFO: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
2024-08-09 01:00:00.632 CEST [199/T203] INFO: ----------------------------> FTL crashed! <----------------------------
2024-08-09 01:00:00.632 CEST [199/T203] INFO: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
2024-08-09 01:00:00.632 CEST [199/T203] INFO: Please report a bug at Issues · pi-hole/FTL · GitHub
2024-08-09 01:00:00.632 CEST [199/T203] INFO: and include in your report already the following details:
2024-08-09 01:00:00.632 CEST [199/T203] INFO: FTL has been running for 54185 seconds
2024-08-09 01:00:00.632 CEST [199/T203] INFO: FTL branch: development-v6
2024-08-09 01:00:00.632 CEST [199/T203] INFO: FTL version: vDev-cce2c21
2024-08-09 01:00:00.632 CEST [199/T203] INFO: FTL commit: cce2c210
2024-08-09 01:00:00.632 CEST [199/T203] INFO: FTL date: 2024-08-04 14:47:39 +0200
2024-08-09 01:00:00.632 CEST [199/T203] INFO: FTL user: started as pihole, ended as pihole
2024-08-09 01:00:00.633 CEST [199/T203] INFO: Compiled for linux/amd64 (compiled on CI) using cc (Alpine 13.2.1_git20240309) 13.2.1 20240309
2024-08-09 01:00:00.633 CEST [199/T203] INFO: Process details: MID: 199
2024-08-09 01:00:00.633 CEST [199/T203] INFO: PID: 199
2024-08-09 01:00:00.633 CEST [199/T203] INFO: TID: 203
2024-08-09 01:00:00.633 CEST [199/T203] INFO: Name: dns-client
2024-08-09 01:00:00.633 CEST [199/T203] INFO: Received signal: Segmentation fault
2024-08-09 01:00:00.633 CEST [199/T203] INFO: at address: 0
2024-08-09 01:00:00.633 CEST [199/T203] INFO: with code: Unknown (128)
2024-08-09 01:00:00.633 CEST [199/T203] INFO: !!! INFO: pihole-FTL has not been compiled with glibc/backtrace support, not generating one !!!
2024-08-09 01:00:00.633 CEST [199/T203] INFO: ------ Listing content of directory /dev/shm ------
2024-08-09 01:00:00.633 CEST [199/T203] INFO: File Mode User:Group Size Filename
2024-08-09 01:00:00.633 CEST [199/T203] INFO: rwxrwxrwx root:root 280 .
2024-08-09 01:00:00.633 CEST [199/T203] INFO: rwxr-xr-x root:root 480 ..
2024-08-09 01:00:00.633 CEST [199/T203] INFO: rw------- pihole:pihole 88 FTL-lock
2024-08-09 01:00:00.633 CEST [199/T203] INFO: rw------- pihole:pihole 292 FTL-counters
2024-08-09 01:00:00.633 CEST [199/T203] INFO: rw------- pihole:pihole 16 FTL-settings
2024-08-09 01:00:00.633 CEST [199/T203] INFO: rw------- pihole:pihole 123K FTL-strings
2024-08-09 01:00:00.633 CEST [199/T203] INFO: rw------- pihole:pihole 135K FTL-domains
2024-08-09 01:00:00.633 CEST [199/T203] INFO: rw------- pihole:pihole 86K FTL-clients
2024-08-09 01:00:00.633 CEST [199/T203] INFO: rw------- pihole:pihole 29K FTL-upstreams
2024-08-09 01:00:00.633 CEST [199/T203] INFO: rw------- pihole:pihole 4M FTL-queries
2024-08-09 01:00:00.633 CEST [199/T203] INFO: rw------- pihole:pihole 8K FTL-overTime
2024-08-09 01:00:00.633 CEST [199/T203] INFO: rw------- pihole:pihole 332K FTL-dns-cache
2024-08-09 01:00:00.633 CEST [199/T203] INFO: rw------- pihole:pihole 8K FTL-per-client-regex
2024-08-09 01:00:00.633 CEST [199/T203] INFO: rw------- pihole:pihole 569K FTL-fifo-log
2024-08-09 01:00:00.633 CEST [199/T203] INFO: ---------------------------------------------------
2024-08-09 01:00:00.633 CEST [199/T203] INFO: Please also include some lines from above the !!!!!!!!! header.
2024-08-09 01:00:00.634 CEST [199/T203] INFO: Thank you for helping us to improve our FTL engine!
2024-08-09 01:00:00.634 CEST [199/T203] INFO: Waiting for threads to join
2024-08-09 01:00:00.634 CEST [199/T203] INFO: Thread database (0) is idle, terminating it.
2024-08-09 01:00:00.634 CEST [199/T203] INFO: Thread housekeeper (1) is idle, terminating it.
2024-08-09 01:00:00.634 CEST [199M] INFO: Shutting down... // exit code 0 // jmpret 0
2024-08-09 01:00:00.642 CEST [199/T204] INFO: Terminating timer thread
2024-08-09 01:00:00.889 CEST [199M] INFO: Finished final database update
2024-08-09 01:00:00.889 CEST [199M] INFO: Waiting for threads to join
2024-08-09 01:00:00.889 CEST [199M] INFO: Thread database (0) is idle, terminating it.
2024-08-09 01:00:00.889 CEST [199M] INFO: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
2024-08-09 01:00:00.889 CEST [199M] INFO: ----------------------------> FTL crashed! <----------------------------
2024-08-09 01:00:00.889 CEST [199M] INFO: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
2024-08-09 01:00:00.889 CEST [199M] INFO: Please report a bug at Issues · pi-hole/FTL · GitHub
2024-08-09 01:00:00.889 CEST [199M] INFO: and include in your report already the following details:
2024-08-09 01:00:00.889 CEST [199M] INFO: FTL has been running for 54185 seconds
2024-08-09 01:00:00.889 CEST [199M] INFO: FTL branch: development-v6
2024-08-09 01:00:00.889 CEST [199M] INFO: FTL version: vDev-cce2c21
2024-08-09 01:00:00.889 CEST [199M] INFO: FTL commit: cce2c210
2024-08-09 01:00:00.889 CEST [199M] INFO: FTL date: 2024-08-04 14:47:39 +0200
2024-08-09 01:00:00.889 CEST [199M] INFO: FTL user: started as pihole, ended as pihole
2024-08-09 01:00:00.889 CEST [199M] INFO: Compiled for linux/amd64 (compiled on CI) using cc (Alpine 13.2.1_git20240309) 13.2.1 20240309
2024-08-09 01:00:00.889 CEST [199M] INFO: Process details: MID: 199
2024-08-09 01:00:00.889 CEST [199M] INFO: PID: 199
2024-08-09 01:00:00.889 CEST [199M] INFO: TID: 199
2024-08-09 01:00:00.889 CEST [199M] INFO: Name: pihole-FTL
2024-08-09 01:00:00.889 CEST [199M] INFO: Received signal: Segmentation fault
2024-08-09 01:00:00.889 CEST [199M] INFO: at address: 0x7ed5e8747b74
2024-08-09 01:00:00.889 CEST [199M] INFO: with code: SEGV_MAPERR (Address not mapped to object)
2024-08-09 01:00:00.889 CEST [199M] INFO: !!! INFO: pihole-FTL has not been compiled with glibc/backtrace support, not generating one !!!
2024-08-09 01:00:00.889 CEST [199M] INFO: ------ Listing content of directory /dev/shm ------
2024-08-09 01:00:00.889 CEST [199M] INFO: File Mode User:Group Size Filename
2024-08-09 01:00:00.890 CEST [199M] INFO: rwxrwxrwx root:root 280 .
2024-08-09 01:00:00.890 CEST [199M] INFO: rwxr-xr-x root:root 480 ..
2024-08-09 01:00:00.890 CEST [199M] INFO: rw------- pihole:pihole 88 FTL-lock
2024-08-09 01:00:00.890 CEST [199M] INFO: rw------- pihole:pihole 292 FTL-counters
2024-08-09 01:00:00.890 CEST [199M] INFO: rw------- pihole:pihole 16 FTL-settings
2024-08-09 01:00:00.890 CEST [199M] INFO: rw------- pihole:pihole 123K FTL-strings
2024-08-09 01:00:00.890 CEST [199M] INFO: rw------- pihole:pihole 135K FTL-domains
2024-08-09 01:00:00.890 CEST [199M] INFO: rw------- pihole:pihole 86K FTL-clients
2024-08-09 01:00:00.890 CEST [199M] INFO: rw------- pihole:pihole 29K FTL-upstreams
2024-08-09 01:00:00.890 CEST [199M] INFO: rw------- pihole:pihole 4M FTL-queries
2024-08-09 01:00:00.890 CEST [199M] INFO: rw------- pihole:pihole 8K FTL-overTime
2024-08-09 01:00:00.890 CEST [199M] INFO: rw------- pihole:pihole 332K FTL-dns-cache
2024-08-09 01:00:00.890 CEST [199M] INFO: rw------- pihole:pihole 8K FTL-per-client-regex
2024-08-09 01:00:00.890 CEST [199M] INFO: rw------- pihole:pihole 569K FTL-fifo-log
2024-08-09 01:00:00.890 CEST [199M] INFO: ---------------------------------------------------
2024-08-09 01:00:00.890 CEST [199M] INFO: Please also include some lines from above the !!!!!!!!! header.
2024-08-09 01:00:00.890 CEST [199M] INFO: Thank you for helping us to improve our FTL engine!
2024-08-09 01:00:00.890 CEST [199M] INFO: Waiting for threads to join
2024-08-09 01:00:00.890 CEST [199M] INFO: Thread database (0) is idle, terminating it.
2024-08-09 01:00:06.032 CEST [5353M] INFO: ########## FTL started on pihole01! ##########
2024-08-09 01:00:06.032 CEST [5353M] INFO: FTL branch: development-v6
2024-08-09 01:00:06.032 CEST [5353M] INFO: FTL version: vDev-cce2c21
2024-08-09 01:00:06.032 CEST [5353M] INFO: FTL commit: cce2c210
2024-08-09 01:00:06.032 CEST [5353M] INFO: FTL date: 2024-08-04 14:47:39 +0200
2024-08-09 01:00:06.032 CEST [5353M] INFO: FTL user: pihole
2024-08-09 01:00:06.032 CEST [5353M] INFO: Compiled for linux/amd64 (compiled on CI) using cc (Alpine 13.2.1_git20240309) 13.2.1 20240309
2024-08-09 01:00:06.035 CEST [5353M] INFO: Wrote config file:

TheBossME · August 9, 2024, 6:36am

Here is the end of FTL.1 file. Issue do appear again. On the network there is no device with „Merros Smart Switch“ naming. I have also checked the Router config. I was wondering why pihole will see such a device name. Strange !

It looks like issue comes up while pihole flush once quiet is running on midnight.

I have now renamed the Meross Smart Switch in the app to that name with blanks. Renewed DHCP.. and in the dhcp it looks now like „Meross-Smart-Switch“ after dhcp reregistration. So will check over weekend what happened now.

2024-08-08 23:30:00.044 CEST [199/T201] INFO: Size of /etc/pihole/pihole-FTL.db is 3.07 MB, deleted 395 rows
2024-08-08 23:40:00.103 CEST [199/T201] INFO: Size of /etc/pihole/pihole-FTL.db is 3.07 MB, deleted 395 rows
2024-08-08 23:50:00.019 CEST [199/T201] INFO: Size of /etc/pihole/pihole-FTL.db is 3.07 MB, deleted 392 rows
2024-08-09 00:00:00.102 CEST [199/T201] INFO: Size of /etc/pihole/pihole-FTL.db is 3.07 MB, deleted 390 rows

DL6ER · August 10, 2024, 4:55am

Please tell us such important details, otherwise, as you've seen, interpretations may go into an entirely wrong direction.

Your latest log excerpt shows two crashes, I think I see what is causing the second one, but not the former. It seems we need to do further debugging to see what is going on exactly. Please follow the instructions here: gdb - Pi-hole documentation

Once the crash happens again, the debugger will halt the process in the faulty state and you can follow the last step (3.). This will hopefully provide enough information to exactly identify (and subsequently fix) this bug.

TheBossME · August 10, 2024, 11:54am

pihole is getting unusable while starting gdb, so I cannot help more actually.

Also clearing up database and start fresh wouldn’t help.

I think the meross device is stored with blanks into the pihole-FTL database. I will analyze from that. The issue with the database and FTL crashes only when this meross device is updating dns/dhcp.
Without having the meross device in the database.. everything’s looking good.

DL6ER · August 10, 2024, 1:09pm

You need to manually type continue + Enter to have FTL continue servicing while being watched by gdb. I thought that's mentioned in the guide, may need to revisit it.

DL6ER · August 10, 2024, 2:10pm

This indicates you tried to restart FTL. Nothing is needed to be done once gdb has been attached.

TheBossME · August 12, 2024, 7:49am

[Detaching after vfork from child process 10766]

Thread 1 "pihole-FTL" received signal SIGTERM, Terminated.

Thread 1 "pihole-FTL" received signal SIG41, Real-time event 41.
__restore_sigs(set=set@entry=0x7fffc915c300)
at ./arch/x86_64/syscall_arch.h:40
40./arch/x86_64/syscall_arch.h: Datei oder Verzeichnis nicht gefunden.
(gdb) backtrace
#0 __restore_sigs(set=set@entry=0x7fffc915c300) at ./arch/x86_64/syscall_arch.h:40
#1 0x00000000007c6fb5in raise(sig=) at src/signal/raise.c:11
#2 0x00000000004236d5in SIGTERM_handler(si=, unused=, signum=) at /app/src/signals.c:414
Backtrace stopped: Cannot access memory at address 0x7fffc915c6f8

DL6ER · August 12, 2024, 4:19pm

This isn't a crash. Something is asking FTL to terminate. This can be either you (e.g. pihole restartdns) or a cronjob or whatever else (e.g. some other automatic script). We first need to eliminate this external influence to keep the debugger attached until the crash is happening.

TheBossME · August 16, 2024, 1:25pm

I have focused where „Meross Smart Switch“ naming is generated.
There where an Alexa instance or Smarthings Instance application running. This could produce the issue. Since I removed Alexa app from my devices and from network, no issue do appear again.