Le Fri, 14 Oct 2016 19:46:13 +0500
"Vladislav Grishenko" <themiron...@gmail.com> a écrit:

> > But timeouts can occur, TTLs can get past, etc. To treat those
> > properly, dnsmasq needs to know how much time has flown while it
> > was sleeping (if it ever does, of course).  
> It does (actually not due sleeping, more likely to timer
> granulation), can be easily checked in code. Despite the fact that
> sleeping DHCP/DNS servers looks quite ridiculous, if dnsmasq code
> without HAVE_BROKEN_RTC has issue with time goes backward too much,
> it needs to be fixed.

I think we can agree on this. :)

> Not with changing the clock source, because
> it'll just mask the problem

Well, IIUC, here the source of the problem *is* the clock source --
namely, that CLOCK_REALTIME is used for measuring elapsed time but is
not monotonic and therefore ill-suited for measuring elapsed time.
Switching to CLOCK_MONOTONIC, which is, well, monotonic, is certainly
not "masking the problem". Switching to CLOCK_BOOTTIME, which is "more
monotonic" yet, is an even better solution if applicable.

>, but with proper dealing with such kind
> of time values. And, seems John have already found last_change
> variable wasn't static, didn’t check it by myself yet.

How exactly is that second  is totally related to how dnsmasq
handles time?

> Best Regards, Vladislav Grishenko


Dnsmasq-discuss mailing list

Reply via email to