[systemd-devel] timesyncd: Frequent polling when no server could be reached

[Kay Sievers]

On Tue, Aug 26, 2014 at 3:37 AM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Fri, 22.08.14 10:13, Miroslav Lichvar (mlichvar at redhat.com) wrote:
>
>> > Polluting my log this way. Is is possible to inhibit that behavior? Maybe
>> > trying a couple of times, then giving up until next network status change.
>>
>> Hm, a well behaved client reduces its polling rate exponentially when
>> it doesn't receive a reply to avoid overloading the servers and
>> network congestion.
>
> So far there's some ratelimit applied to avoid flooding
> servers. However, we should probably extend this into some exponential
> backoff logic.

There is logic in there thas does:
  /* re-arm timer with increasing timeout, in case the packets never
arrive back */

Maybe that does not work anymore with the try-the-next-server handling.

>> BTW, I was getting segfaults with current git in sd_resolve_getaddrinfo()
>> in manager_connect() when doing the tests, removing the
>> server_name_flush_addresses() call seems to fix it.
>
> Hmm, this sounds like a ref counting issue in sd_resolve. I am on it.
>
>> > Another question I have is about the NTP status output of timedatectl.
>> >
>> > Right now (with ntpd running) it says:
>> >
>> > NTP enabled: yes
>> > NTP synchronized: no
>> >
>> > I suppose it need some more uptime than the 11 minutes I have currently?
>>
>> Possibly, ntpd needs to clear the STA_UNSYNC flag in adjtimex to mark
>> the clock as synchronized.
>
> Kay, can you comment?

If ntpd is running, timedatectl should not show "enabled: yes", we
only look for timesyncd. Please check that again, there seems
something wrong in the setup.

The "synchronized" flag comes straigt from the kernel like mentioned
above, there is no other setting involved, seems like a ntpd problem.

Kay