Re: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an hour

2016-10-13 Thread Albert ARIBAUD
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 wou

Re: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an hour

2016-10-13 Thread John Knight
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 cas

Re: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an hour

2016-10-13 Thread Vladislav Grishenko
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_BRO

Re: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an hour

2016-10-13 Thread Albert ARIBAUD
Hi, I think it is preferable not to use HAVE_BROKEN_RTC for at least two reasons, in increasing order of importance: 1. HAVE_BROKEN_RTC should be used for, well, broken RTCs. Here, we are not dealing with broken RTC. 2. The man mage for times() states that "a portable application would be wis

Re: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an hour

2016-10-13 Thread John Knight
Hi All, Well, I believe I have found another issue with the function poll_resolv(). The variable last_change needs to be static. Otherwise, the difftime(statbuf.st_mtime, last_change) always is a rather large number... the number of seconds since time 0 (the initialized value of last_change a