FTL webserver thread goes idle and terminates after extended uptime (Pi Zero 2W, v6.4)

[nicoleman0]

Versions

• Pi-hole: v6.4
• Web: v6.4.1
• FTL: v6.5

Platform

• OS and version: Raspberry Pi OS Lite (64-bit)
• Platform: Raspberry Pi Zero 2W

Expected behavior

FTL runs indefinitely with the web UI remaining accessible.

Actual behavior / bug

After extended uptime (~15-16 hours), FTL's internal webserver thread goes idle, after which FTL terminates cleanly (code 0). The web UI becomes unreachable. DNS and DHCP may recover if FTL restarts automatically, but the web UI does not.

FTL log:

2026-03-07 09:03:50.108 GMT [1037M] INFO: Thread webserver (7) is idle, terminating it.
2026-03-07 09:03:50.108 GMT [1037M] INFO: All threads joined
2026-03-07 09:03:50.693 GMT [1037M] INFO: ########## FTL terminated after 15h 50m 45s (code 0)! ##########

Steps to reproduce

1. Run Pi-hole v6.4 on a Pi Zero 2W with normal household DNS/DHCP traffic
2. Leave running for ~15-16 hours
3. Web UI becomes unreachable

Debug Token

• URL: https://tricorder.pi-hole.net/uYcOEJI6/

Additional context

Hardware appears healthy — vcgencmd get_throttled returns 0x0, no undervolt or thermal events logged.

A cron job to restart FTL if the web UI becomes unreachable:

*/15 * * * * curl -sk http://localhost/ | grep -q "Pi-hole" || systemctl restart pihole-FTL

[nicoleman0]

Update following second failure:

The issue recurred approximately 7 hours after the first. On the next boot, FTL logged the following:

ERROR: SQLite3: recovered 296 frames from WAL file /etc/pihole/pihole-FTL.db-wal (283)

This suggests the previous shutdown was not clean. The database WAL file was not flushed, indicating FTL may have been killed abruptly rather than exiting gracefully. This potentially contradicts the earlier code 0 observation and may point to a separate or compounding failure mode.

Also noting that Restart=on-failure in the systemd override did not trigger a restart after the first failure, consistent with a code 0 exit. So I changed to Restart=always as a mitigation.

[yubiuser]

Usually, FTL logs in FTL.log which process asked to terminate it. Is there an clue in the logs?

[nicoleman0]

Usually, FTL logs in FTL.log which process asked to terminate it. Is there any clue in the logs?

Unfortunately I wasn't able to find the full log context around the termination. It looks like it was lost after the subsequent unclean shutdown. The lines in the issue are all I managed to capture at the time.

[scoulea]

I also have this problem, my syslog shows,

2026-03-19T20:48:35.491093+00:00 raspberrypi systemd[1]: pihole-FTL.service: Main process exited, code=exited, status=1/FAILURE
�����������������2026-03-19T20:48:35.572964+00:00 raspberrypi systemd[1]: pihole-FTL.service: Failed with result 'exit-code'.������������������������������������
2026-03-19T20:48:35.574819+00:00 raspberrypi systemd[1]: pihole-FTL.service: Consumed 9min 51.613s CPU time.������������������������������������
2026-03-19T20:48:40.752250+00:00 raspberrypi systemd[1]: pihole-FTL.service: Scheduled restart job, restart counter is at 5.�������
I’ll do some more digging

[scoulea]

https://tricorder.pi-hole.net/2Rt1MIWK/ ���
The FTL log shows the termination as

2026-03-19 20:09:16.019 GMT [11999/T16086] INFO: Received signal: Segmentation fault������������������������������������������������������������
2026-03-19 20:09:16.019 GMT [11999/T16086] INFO: at address: 0�����������������������������������������������������������������������������
2026-03-19 20:09:16.019 GMT [11999/T16086] INFO: with code: SEGV_MAPERR (Address not mapped to object)���

[rdwebdesign]

@scoulea

It seems you have a different issue, resulting in a Segmentation fault.

You debug log doesn't show a recent crash and nothing indicates an issue.

On the other hand, the logs posted above shows your filesystem is probably corrupted (these "������" characters are not expected in normal log files).
This is an indication that your SD card is probably failing/dying.

[nicoleman0]

I forgot to update this, but I've since been running with a workaround, if anyone else is interested.

The immediate fix is a cron job that restarts FTL if the web UI stops responding:

*/15 * * * * curl -sk http://localhost/ | grep -q "Pi-hole" || systemctl restart pihole-FTL

This catches the idle-thread shutdown within 15 minutes. Checking for actual Pi-hole HTML rather than just a successful connection is more reliable than a simple connectivity check.

I also set FTL to restart automatically on failure via a systemd override (sudo systemctl edit pihole-FTL):

[Service]
Restart=on-failure
RestartSec=10

That doesn't help with this specific case (since FTL exits cleanly with code 0), but it covers other crash scenarios.

The core issue remains though. FTL's webserver thread going idle after ~15-16 hours of uptime triggers a clean process shutdown, which takes down DNS and DHCP with it. Would be good to understand whether this is expected behavior or a bug in thread lifecycle management.

Also, since I implemented the workaround - I've had my Pihole up for 10 days with no interruptions.

[yubiuser]

Would be good to understand whether this is expected behavior or a bug in thread lifecycle management.

This is not considered normal behavior.

Could you disable your workaround cron script and try to get the FTL.log lines which process made it shutdown?

[DL6ER]

@nicoleman0 Thanks for the detailed report.

I audited every code path in FTL that can set the global killed flag (which is what makes the dnsmasq main loop, and therefore FTL itself, exit) and I can confirm there is no internal path that triggers a spontaneous shutdown.

The "Thread webserver (7) is idle, terminating it" line is unfortunately a red herring: that thread is the certificate-renewal worker which sleeps for 24 hours between checks, so when shutdown begins it is essentially always sleeping ("idle"). The actual web server (CivetWeb) runs on its own threads and is shut down separately later.

So the cause of the shutdown is something external sending SIGTERM, and the reason you couldn't pin it down is that the diagnostic info that would identify it was either logged at DEBUG level (invisible in production) or written far above the final "FTL terminated" line and lost when you tailed the log.

---

PR #2839 closes both gaps: it persists the SIGTERM sender info and re-logs it as Terminated by "<name>" (PID <n>, user <name> UID <n>) immediately before the final termination banner and promotes the "Shutting down (exit code, jmpret)" line from DEBUG to production (INFO level).

Please run

sudo pihole checkout ftl fix/log-shutdown-source-2818

to grab this change onto your local system.

With this, the next time it happens you should see something like INFO: Terminated by "systemd" (PID 1, user root UID 0) right next to the ########## FTL terminated after ... line, which will tell us whether the killer is systemd (memory pressure / OOM via cgroup, log rotation hook, an automatic update touching the service, etc.), a cron job, or something else entirely. If you can run with this once it's merged and capture the next occurrence, we should be able to identify the culprit immediately.

---

In the meantime your Restart=always mitigation and the cron health-check are both reasonable - on a Pi Zero 2W with 512 MB, my strongest suspicion is systemd or the kernel reclaiming memory under pressure, but the new logging will tell us for sure rather than guessing.