I've seen several topics discussing the "getOverTimeID" error and thought I would share what I found.
On my system, I was seeing this error in /var/log/pihole-FTL.log for every DNS query that came in. Checking my /etc/rc2.d startups, S02pihole-FTL was starting IMMEDIATELY after S02ntp, but a fraction of a second BEFORE NTP had updated the system time. So, when pihole-FTL starts, it thinks it's December 31, 1969 @ 18:00 (in my timezone). Then NTP fast-forwards the date by 51 years and pihole-FTL is not happy about it.
So, the fix for me was to add a "sleep 2" in the /etc/init.d/pihole-FTL startup script, above the "if setcap CAP_NET_BIND_SERVICE...." line, in the start() section.
Well, bad news. I did the DELAY_STARTUP option, and it DOES delay until after ntp is update the date:
[1969-12-31 18:01:01.477 1642M] Sleeping for 3 seconds as requested by configuration ...
[2021-03-27 06:24:06.702 1642M] Done sleeping, continuing startup of resolver...
But still get the getOverTimeID errors, I'm guessing because the internal date it's using was set at initial startup, before the delay.
[2021-03-27 06:35:30.166 1702M] WARN: getOverTimeID(1616844900): 2694885 is too large: 18446744073709465516
[2021-03-27 06:35:30.219 1702M] New upstream server: 192.168.1.254:53 (0/1024)
[2021-03-27 06:35:30.528 1702M] WARN: getOverTimeID(1616844900): 2694885 is too large: 18446744073709465516
So unless there's another option I'm missing, I'm going to call a little script in pihole-FTL startup that waits until the date has been updated. I can post it if anybody's interested.
We should rather change when the delay is added. We do all the start-up right now (like loading data from the database!) and then add the delay before starting the resolver. We can just move the delay in front of everything else (right after config option processing) to resolve this.
No, doesn't seem to be. I'm running Debian 9 on a PogoPlug device. It's using ntpd, whereas my raspberry pi that's running pihole and doesn't seem to have this problem is running systemd-timesyncd, if that makes any difference.
Wasn't familiar with that, but looks like that does what jfb was mentioning - saving the time on shutdown and restoring it on startup. I'll take a look at that.
Update: I was able to install fake-hwclock. Interesting note: it defaults to only starting in runlevel 5. My pogoplugs boot to runlevel 2, so had to add S01 link in /etc/rc2.d. Still would be nice if DELAY_STARTUP would work for me. Maybe just update internal Time variable after DELAY_STARTUP?