Hi,
Why not just use existing HAVE_BROKEN_RTC?CLOCK_BOOTIME is linux-specific, 
non-portable, absent in older (but still running) kernels and logically is the 
same as CLOCK_MONOTONIC except counting suspended/sleep time. In turn using 
CLOCK_MONOTONIC is already there in times() form when HAVE_BROKEN_RTC is 
enabled.

Best Regards, Vladislav Grishenko

                _____________________________
From: John Knight <john.kni...@belkin.com>
Sent: четверг, октября 13, 2016 11:00 ПП
Subject: Re: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an hour
To: Albert ARIBAUD <albert.arib...@free.fr>
Cc:  <dnsmasq-discuss@lists.thekelleys.org.uk>


Hi Albert,

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.

Thanks!

John




-----Original Message-----
From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
Sent: Thursday, October 13, 2016 2:16 AM
To: John Knight
Cc: dnsmasq-discuss@lists.thekelleys.org.uk
Subject: Re: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an hour

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.

__________________________________________________________________ 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
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss



        
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Reply via email to