[systemd-devel] [PATCH] timedated: add configure option to set name of controlled NTP service

[Miroslav Lichvar]

On Tue, Aug 26, 2014 at 02:21:10PM +0200, Lennart Poettering wrote:
> On Tue, 26.08.14 11:41, Miroslav Lichvar (mlichvar at redhat.com) wrote:
> > To have timedated/timedatectl managing the right NTP service on
> > distributions like Fedora.
> 
> I don't really think that timedated should manage an NTP server like
> ntpd/chrony. 

I'm talking about NTP clients, not servers. Writing a good NTP client
is the difficult part, making server from a client is just a matter of
binding a socket to port 123 and replying to the requests with current
time. Anyway, chronyd doesn't reply to NTP requests by default, so
think of it as an NTP client in this context.

> timedated's primary job is to be a service to GNOME and
> other DEs. But if an admin wants to upgrade to a full NTP server, then
> he should really enable/disable that with "systemctl" or a similar
> command.

Distributions usually have a full NTP client installed by default, why
should GNOME try to enable/disable an SNTP client that happens to be
distributed with systemd?

> The code wasn't wrong for what it was supposed to do. We just didn't
> think the complexity of it would be appropriate.

Ok, this patch to make it configurable at compilation time is
extremely simple and there is zero runtime cost, so there should be no
problem in including it, or not?

> > 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,
> 
> I don't see why timesyncd would be any different regarding monotonicity
> that chrony would...

After start chronyd uses only slewing to correct the clock, but timesyncd
seems to step the clock when the offset is larger than 0.4 second and
is not a spike. With an intermittent or congested internet connection
suffering from bufferbloat it's pretty easy to get offsets larger than
that.

> > 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.
> 
> Well, if we start comparing features, then there's also some stuff that
> timesyncd can do that chrony can't (such as getting NTP server info from
> DHCP networkd, or support for offline clock monotonicity of RTC-less
> systems). 

Ok, chronyd is usually used with NetworkManager and it relies on a
dispatcher script to get the servers from DHCP. Adding support to get
them from networkd doesn't sound like a very difficult task if it's
needed. Or could be networkd modified to write the list of the servers
to a file so any NTP client could use it?

As for systems without RTC, chronyd now has an option to restore the
time similarly to the fake-hwclock script from Debian.

> > 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.
> 
> Well, I don't see why a Linux client should implement a full NTP server
> if no other OS does that...

Vendors of other systems (at least Apple and Microsoft) can afford to
run their own NTP servers. SNTP is probably good enough for them.

> This is really about being a *client*, and
> not trying to outsmart servers.

Outsmart servers how exactly?

> > 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.).
> 
> we are not a vendor, as we don't really do products. Vendors may use
> systemd to build a product, but in that case they should use
> --with-ntp-servers= and set their own NTP servers of choice...

Did you ask them? I think they would be ok with systemd having its own
vendor zone, systemd is not that far to be considered a Linux
distribution. :)

-- 
Miroslav Lichvar