Total queries timeline not advancing when logging is disabled

[mbecher]

Versions

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

Platform

• OS and version: Debian 13 Trixie / Linux pi 6.12.62+rpt-rpi-v8
• Platform: Raspberry Pi 4 Model B Rev 1.1

Expected behavior

The total queries timeline should advance as usual.

Actual behavior / bug

The total queries timeline collects all queries at the 10min when pihole-FTL was restarted at the right of the timeline. Enabling logging resolves this issue and everything works as expected. Re-disabling query logging and setting anonymous mode brings the error back.

Steps to reproduce

Steps to reproduce the behavior:

1. Go to 'Settings/Privacy'
2. Deselect 'Log DNS queries and replies' then enable 'Anonymous mode'
3. Watch the total queries timeline in the dashboard
4. See error

Debug Token

• URL: https://tricorder.pi-hole.net/2JySHl8x/

Screenshots

[yubiuser]

Interesting. It looks like a bug, but could not reproduce myself.
This is how my timeline looked before enabling 'Anonymous mode'

and this is it now

the timeline clearly progressed

---

You activity looks empty before ~ 09:00. Was this really the case or was everything smashed into the bar at 09:00?

[mbecher]

Yes, I removed pihole-FTL.db and restarted pihole-FTL at 9.00, because I had query logging enabled to see whether it would make a difference. With logging enabled the timeline progressed as usual. This instance of pihole has been running for many years without any major problems and does a really great job. The timelime issue occurred right after updating pihole last week.

Also, I have the longterm query database disabled via pihole -l off so starting from zero, whenever I restart pihole-FTL, is what I would expect.

[rdwebdesign]

Do you see the same using different browsers or accessing from a different device?

[mbecher]

Yes. I checked it on Firefox/Linux and Safari/iOS.

[yubiuser]

Here is a similar report (same symptoms) but with query logging enabled and not using anonymous mode:
https://discourse.pi-hole.net/t/dashboard-does-not-update-shows-static-vertical-bar/85164

[yubiuser]

Could you please run from the terminal

(sudo) pihole api history and post the output?

[mbecher]

Sorry, had to get my hands dirty ...

Here's the output of pihole api history:

pihole-api-history.txt

[yubiuser]

Ok, this is the same situation as in the linked discourse topic: only the last timeslot is populated with data. This is an FTL issue, not a web interface display issue.

[mbecher]

And, since this has been asked on the related bug report, here's the output of pihole-FTL sqlite3 /etc/pihole/pihole-FTL.db "SELECT min(timestamp),max(timestamp), count(*) FROM queries;" as well: 1771746570.27226|1771747280.00692|166

The date on this machine looks correct.

[DL6ER]

Could you maybe do what I suggested here?

https://discourse.pi-hole.net/t/dashboard-does-not-update-shows-static-vertical-bar/85164/22?u=dl6er

Once we have the relevant output, it should be a lot easier to find the issue as I am myself not able to reproduce right now, too.

[mbecher]

Yes, of course ... Here you are: https://tricorder.pi-hole.net/aB1DerTx/

[yubiuser]

It initialized 145 slots empty

2026-02-25 17:13:25.989 CET [21108M] DEBUG_OVERTIME: initOverTime(): Initializing 145 slots from 2026-02-24 17:15:00 (1771949700) to 2026-02-25 17:15:00 (1772036100)
2026-02-25 17:13:25.989 CET [21108M] DEBUG_OVERTIME: initSlot(0, 1771949700): Zeroing overTime slot at 2026-02-24 17:15:00
2026-02-25 17:13:25.989 CET [21108M] DEBUG_OVERTIME: initSlot(1, 1771950300): Zeroing overTime slot at 2026-02-24 17:25:00
2026-02-25 17:13:25.989 CET [21108M] DEBUG_OVERTIME: initSlot(2, 1771950900): Zeroing overTime slot at 2026-02-24 17:35:00
2026-02-25 17:13:25.989 CET [21108M] DEBUG_OVERTIME: initSlot(3, 1771951500): Zeroing overTime slot at 2026-02-24 17:45:00
2026-02-25 17:13:25.989 CET [21108M] DEBUG_OVERTIME: initSlot(4, 1771952100): Zeroing overTime slot at 2026-02-24 17:55:00
2026-02-25 17:13:25.989 CET [21108M] DEBUG_OVERTIME: initSlot(5, 1771952700): Zeroing overTime slot at 2026-02-24 18:05:00
2026-02-25 17:13:25.989 CET [21108M] DEBUG_OVERTIME: initSlot(6, 1771953300): Zeroing overTime slot at 2026-02-24 18:15:00
2026-02-25 17:13:25.990 CET [21108M] DEBUG_OVERTIME: initSlot(7, 1771953900): Zeroing overTime slot at 2026-02-24 18:25:00
2026-02-25 17:13:25.990 CET [21108M] DEBUG_OVERTIME: initSlot(8, 1771954500): Zeroing overTime slot at 2026-02-24 18:35:00
....
2026-02-25 17:13:25.996 CET [21108M] DEBUG_OVERTIME: initSlot(144, 1772036100): Zeroing overTime slot at 2026-02-25 17:15:00

... then it said no query from database to import...

026-02-25 17:13:26.002 CET [21108M] INFO: Database successfully initialized
2026-02-25 17:13:26.293 CET [21108/T21110] INFO:  -> Total DNS queries: 0
2026-02-25 17:13:26.293 CET [21108/T21110] INFO:  -> Cached DNS queries: 0
2026-02-25 17:13:26.293 CET [21108/T21110] INFO:  -> Forwarded DNS queries: 0
2026-02-25 17:13:26.293 CET [21108/T21110] INFO:  -> Blocked DNS queries: 0
2026-02-25 17:13:26.293 CET [21108/T21110] INFO:  -> Unknown DNS queries: 0
2026-02-25 17:13:26.293 CET [21108/T21110] INFO:  -> Unique domains: 0
2026-02-25 17:13:26.293 CET [21108/T21110] INFO:  -> Unique clients: 0
2026-02-25 17:13:26.293 CET [21108/T21110] INFO:  -> DNS cache records: 0

... but it started to fill the last slot with queries

2026-02-25 17:13:36.623 CET [21108M] DEBUG_OVERTIME: getOverTimeID(1772036100): 144
2026-02-25 17:13:36.623 CET [21108M] DEBUG_OVERTIME: getOverTimeID(1772036100): 144
2026-02-25 17:13:36.623 CET [21108M] DEBUG_OVERTIME: overTime[144].total += 1 = 1
2026-02-25 17:13:36.634 CET [21108M] DEBUG_OVERTIME: getOverTimeID(1772036100): 144
2026-02-25 17:13:36.634 CET [21108M] DEBUG_OVERTIME: overTime[144].forwarded++ = 1 (new_status = FORWARDED), ID = 1
2026-02-25 17:13:36.637 CET [21108M] DEBUG_OVERTIME: getOverTimeID(1772036100): 144
2026-02-25 17:13:36.637 CET [21108M] DEBUG_OVERTIME: getOverTimeID(1772036100): 144
2026-02-25 17:13:36.637 CET [21108M] DEBUG_OVERTIME: overTime[144].total += 1 = 2
2026-02-25 17:13:36.637 CET [21108M] DEBUG_OVERTIME: getOverTimeID(1772036100): 144
2026-02-25 17:13:36.637 CET [21108M] DEBUG_OVERTIME: overTime[144].forwarded++ = 2 (new_status = FORWARDED), ID = 2
2026-02-25 17:13:36.638 CET [21108M] DEBUG_OVERTIME: getOverTimeID(1772036100): 144
2026-02-25 17:13:36.638 CET [21108M] DEBUG_OVERTIME: getOverTimeID(1772036100): 144
2026-02-25 17:13:36.638 CET [21108M] DEBUG_OVERTIME: overTime[144].total += 1 = 3
....

At one point it forked the import and later continued in the main thread

2026-02-25 17:13:37.310 CET [21108M] DEBUG_OVERTIME: overTime[144].total += 1 = 11
2026-02-25 17:13:37.310 CET [21108M] DEBUG_OVERTIME: getOverTimeID(1772036100): 144
2026-02-25 17:13:37.310 CET [21108M] DEBUG_OVERTIME: overTime[144].forwarded++ = 11 (new_status = FORWARDED), ID = 12
2026-02-25 17:13:37.312 CET [21119/F21108] DEBUG_OVERTIME: getOverTimeID(1772036100): 144
2026-02-25 17:13:37.312 CET [21119/F21108] DEBUG_OVERTIME: getOverTimeID(1772036100): 144
2026-02-25 17:13:37.312 CET [21119/F21108] DEBUG_OVERTIME: overTime[144].total += 1 = 12
2026-02-25 17:13:37.312 CET [21119/F21108] DEBUG_OVERTIME: getOverTimeID(1772036100): 144
2026-02-25 17:13:37.312 CET [21119/F21108] DEBUG_OVERTIME: overTime[144].forwarded++ = 12 (new_status = FORWARDED), ID = 12
2026-02-25 17:13:37.316 CET [21108M] DEBUG_ANY: dnsmasq received signal 17
2026-02-25 17:13:40.312 CET [21108/T21109] INFO: Received 8/8 valid NTP replies from 10.0.0.1
2026-02-25 17:13:40.312 CET [21108/T21109] INFO: NTP time offset: -1.333682e+01 ms (excluded 2 outliers)
2026-02-25 17:13:40.312 CET [21108/T21109] INFO: NTP round-trip delay: 4.081726e-01 ms (excluded 2 outliers)
2026-02-25 17:14:03.082 CET [21108M] DEBUG_OVERTIME: getOverTimeID(1772036100): 144
2026-02-25 17:14:03.083 CET [21108M] DEBUG_OVERTIME: getOverTimeID(1772036100): 144
2026-02-25 17:14:03.083 CET [21108M] DEBUG_OVERTIME: overTime[144].total += 1 = 13

[rdwebdesign]

This is expected. All new queries will be added to the last timeslot (144), but this log is too short and we don't see the timeslots "moving".

We need to wait a few more minutes to wait to see what happens when the moveOverTimeMemory() function is executed. Something like this:

2026-02-25 16:09:00.060 DEBUG_OVERTIME moveOverTimeMemory(): IS: 1771959900, SHOULD: 1771960500, MOVING: 1
2026-02-25 16:09:00.060 DEBUG_OVERTIME moveOverTimeMemory(): Moving overTime 1 - 145 to 0 - 144
2026-02-25 16:09:00.060 DEBUG_OVERTIME initSlot(144, 1772046900): Zeroing overTime slot at 2026-02-25 16:15:00

Note: This function is executed once every 10 minutes, so we will need to wait up to 10 minutes to see this output in the logs.

[mbecher]

Thought it would be a little short, so I kept it running with debug.overtime set a little longer, hth: https://tricorder.pi-hole.net/JrEOseYt/