[systemd-devel] [PATCH] timedated: add configure option to set name of controlled NTP service
mlichvar at redhat.com
Tue Aug 26 02:41:42 PDT 2014
On Tue, Aug 26, 2014 at 03:27:10AM +0200, Lennart Poettering wrote:
> On Thu, 21.08.14 12:49, Miroslav Lichvar (mlichvar at redhat.com) wrote:
> > This is useful for installations where some other service than
> > systemd-timesyncd is used to synchronize the system clock.
> What's the rationale here?
To have timedated/timedatectl managing the right NTP service on
distributions like Fedora.
> We recently removed support for configuring arbitrary NTP servers from
> timedated, see b72ddf0f4f552dd53d6404b6ddbc9f17d02b8e12. YOu patch would
> undo this change, but in a very limited way...
Yes, it's meant to be a cheap replacement for the removed functionality.
Perhaps I could prepare something better if I knew what exactly was
wrong with the old code.
> We decided to make timedated only manage timesyncd and nothing else, and
> treat all other NTP servers as real servers that when installed and
> enabled replace timesyncd. Hence: every other NTP server should really
> take precedence over timesyncd, but only timesyncd is managable via
The problem is timedated doesn't see or control the other NTP service.
It may report the "NTP enabled" status incorrectly and "set-ntp false"
may not actually disable NTP. Enabling NTP starts timesyncd, but after
reboot there is the other NTP service running again. This is
> This sounds like the right thing to do, after all timesyncd
> is really the simplest option to run for clients, and hence really is
> what should be managed by GNOME.
I think GNOME should be managing the NTP service which is normally
used on the system, i.e. chronyd on Fedora.
If your suggestion is to use timesyncd by default on all systems
where systemd is included, that might not work. Even if you don't care
much about accuracy, stability or monotonicity of the system clock,
there is a problem with reliability. As timesyncd currently implements
only SNTP and not full NTP client, it doesn't compare times from
multiple servers, so it can't know when a server is broken and another
should be selected instead.
When the client is configured to use just one trusted NTP server,
that's ok. However, when public servers are used, a full NTP client is
preferred to avoid tracking a server whose clock is completely off or
is too slow/fast and is being periodically reset.
BTW, is there an agreement with Google on using their NTP servers?
>From what I could find they don't seem to offer it as a public service
and there is really not much value in knowing how well are the clients
keeping time (unlike knowing what sites people visit from their DNS
requests), so I'd not be very surprised if they started to limit the
access in the future.
You may want to consider getting a vendor zone for systemd at
pool.ntp.org and use it in the default list instead (after making sure
there are no problems with frequent polling, etc.).
More information about the systemd-devel