That sounds like a very good idea to use CLOCK_BOOTTIME. Good suggestion.
When I did a search for difftime in the source code... there are quite a few
calls... each one is a potential issue with respect to time going backwards. I
only see one instance that actually considers the case if time goes backwards
and that is in dnsmasq.c where it does difftime(now, daemon->last_resolv) and
compares the result to both > 1.0 and < -1.0. So in general, I am somewhat
concerned about possible affects of changing time on dnsmasq. We have seen
some issues in the past which we suspected were probably caused by changing the
time, so your suggested change could potentially fix some other issues.
From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
Sent: Thursday, October 13, 2016 2:16 AM
To: John Knight
Subject: Re: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an hour
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:
> 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
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:
Dnsmasq-discuss mailing list