Hi, 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. HTH, Amicalement, Albert. 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 > __________________________________________________________________ Amicalement, -- Albert. _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss