getOverTimeID is too large warning

General
1

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.

Hopefully this helps somebody else.

2

There is no need to modify your local code. This is an existing option for Pi-hole configuration:

DELAY_STARTUP=

https://docs.pi-hole.net/ftldns/configfile/

3

Oh, very cool. Thank you very much.

4

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.

rsantag

5

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.

Any objections anyone?

edit

7

Either that, or wait until after the delay to set the variable it's using for its start-time.

8

What is different about your system where it has the wrong time on startup? Is it not saving the time on shutdown?

9

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.

10

I run fake-hwclock on my Debian PogoPlugs and it solves any time related issues. Not sure if this is what you need but thought I'd throw it out there.

11

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?

18

Oops, my mistake. fake-hwclock was starting in /etc/rcS.d, not /etc/rc5.d, which in hindsight makes more sense. So don't need to add /etc/rc2.d link.

19

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.