Just a generic comment: from what I can see, all absolute times in
dnsmasq are returned bu dnsmasq_time() which calls either times() or
time(). This, IIUC, corresponds to CLOCK_REALTIME in clock_gettime(),
which is indeed affected when (re)setting the time.

Maybe a fix to time jump issues would be (in Linux at least) to replace
time() with clock_gettime(CLOCK_BOOTTIME,...) which seems to have been
designed to get around discontinuities caused by settimeofday(). 

Note: maybe dates used for logging purposes should still use time() or
clock_gettime(CLOCK_REALTIME) in order to remain comparable to other
logs in the same system -- or maybe not.

Sources: man times, man time, man clock_gettime.



Le Wed, 12 Oct 2016 23:50:11 +0000
John Knight <john.kni...@belkin.com> a écrit:

> Hi,
> I think I may know what the issue is... it appears that the time may
> be changed by ntp in my failure scenario as suggested by the URLs
> referencing ntp in the dnsmasq.log file.  There are numerous
> references to difftime in dnsmasq code.  One of which acknowledges
> potential problem if the clock goes backwards... and is handled by
> comparing last_resolv >1.0 and < -1.0 to accommodate such a
> possibility.  However, in function poll_resolv(), the difftime() call
> checks for > 0.0, assuming the modification time of the file is
> greater than the last_change time.  If the time had changed on the
> router, then its possible that the modification time of
> the /etc/resolv.conf could be less than that of the last_change.  I
> think this needs to be a check for != 0.  If the time is changed
> negatively, then the existing code will not work properly me thinks.
> Its imperative that latest gets set in order for the reload_servers()
> code to run... and if the time is not right, then the
> reload_servers() won't get called.  This specific code (poll_resolv)
> hasn't changed, and if I am right, it is also broken in 2.76.
> What do you think?  I am going to make the change locally and re-test
> and see if I can make it fail again.  Unfortunately, it doesn't
> always fail, but I have reproduced it twice now, hopefully it will
> happen again if my fix is not right.
> Best Regards,
> John Knight
> __________________________________________________________________
> Confidential This e-mail and any files transmitted with it are the
> property of Belkin International, Inc. and/or its affiliates, are
> confidential, and are intended solely for the use of the individual
> or entity to whom this e-mail is addressed. If you are not one of the
> named recipients or otherwise have reason to believe that you have
> received this e-mail in error, please notify the sender and delete
> this message immediately from your computer. Any other use,
> retention, dissemination, forwarding, printing or copying of this
> e-mail is strictly prohibited. Pour la version fran?aise:
> http://www.belkin.com/email-notice/French.html F?r die
> deutsche ?bersetzung: http://www.belkin.com/email-notice/German.html
> __________________________________________________________________


Dnsmasq-discuss mailing list

Reply via email to