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

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

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

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

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