On Fri, 22.08.14 10:13, Miroslav Lichvar (mlich...@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. > 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? Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
