On Wed, 04.02.15 18:18, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> On Wed, Feb 04, 2015 at 06:10:40PM +0100, Lennart Poettering wrote: > > On Wed, 04.02.15 17:09, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) > > wrote: > > > > > On Wed, Feb 04, 2015 at 08:06:44AM -0800, Lennart Poettering wrote: > > > > src/timesync/timesyncd-manager.c | 4 ++-- > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > New commits: > > > > commit 7e3254b3bae19221afefdb87b61ff92c755fd2f4 > > > > Author: Lennart Poettering <lenn...@poettering.net> > > > > Date: Wed Feb 4 17:00:23 2015 +0100 > > > > > > > > timesyncd: downgrade more log messages from LOG_INFO to LOG_DEBUG > > > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=87505 > > > > > > > > Let's make timesyncd less chatty. > > > > > > > > diff --git a/src/timesync/timesyncd-manager.c > > > > b/src/timesync/timesyncd-manager.c > > > > index d3c62c9..223671c 100644 > > > > --- a/src/timesync/timesyncd-manager.c > > > > +++ b/src/timesync/timesyncd-manager.c > > > > @@ -285,7 +285,7 @@ static int manager_clock_watch(sd_event_source > > > > *source, int fd, uint32_t revents > > > > } > > > > > > > > /* resync */ > > > > - log_info("System time changed. Resyncing."); > > > > + log_debug("System time changed. Resyncing."); > > > > m->poll_resync = true; > > > > > > > > return manager_send_request(m); > > > > @@ -740,7 +740,7 @@ static int manager_begin(Manager *m) { > > > > m->poll_interval_usec = NTP_POLL_INTERVAL_MIN_SEC * > > > > USEC_PER_SEC; > > > > > > > > server_address_pretty(m->current_server_address, &pretty); > > > > - log_info("Using NTP server %s (%s).", strna(pretty), > > > > m->current_server_name->string); > > > > + log_debug("Using NTP server %s (%s).", strna(pretty), > > > > m->current_server_name->string); > > > > sd_notifyf(false, "STATUS=Using Time Server %s (%s).", > > > > strna(pretty), m->current_server_name->string); > > > > > > Hm, but isn't the problem elsewhere? The bug report stated that ipv6 > > > router advertisements cause timesyncd to resync, spamming the time > > > servers. > > > > Indeed. Reopened. > > > > Not sure what the right approach here is though... > > Maybe we should just set a flag and ignore network changes until the > normal time for the next sync comes, if we were already sucessfully > synced. Hmm, what about this: - If we managed to get a successful sync, don't act on the event, just wait for the next normal resync - If we did not manage to get a successful sync, try again immediately, but not any more often than once per 10s or so... I think this should make the thing pretty robust and responsive to network changes when necessary, but not flood the network needlessly? Makes sense? Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
