On Tue, 26.08.14 11:41, Miroslav Lichvar (mlich...@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.
I don't really think that timedated should manage an NTP server like ntpd/chrony. 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. The idea is that timesyncd is the default, and what the DEs control. But if the admin installs any othr package, then that takes precedence. > > 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. The code wasn't wrong for what it was supposed to do. We just didn't think the complexity of it would be appropriate. > > 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 > > timedated. > > 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 > confusing. Well, if admins installed a full NTP server, then they should control it with "systemctl enable" and "systemctl disable", and it should take precedence, but "timedatectl" is really not supposed to be that. > > 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. I disagree. GNOME is client software, timesyncd is client software, and not more. I am really not convinced that GNOME should be a frontend for a full NTP server suite. > 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... > 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). But it isn't really about that. It's really just about whether "timedatectl" should manage arbitrary NTP serves, or just the one minimal SNTP client that we provide. > 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... This is really about being a *client*, and not trying to outsmart servers. > > BTW, is there an agreement with Google on using their NTP servers? Well, but the pool.ntp.org site makes clear that there's no way we can use theirs, Google at least doesn't do that, so we default to that. The idea is actually that at configure time the distros specify which NTP server to use by default, and use their distro-specific vendor zone from pool.ntp.org. However I simply forgot adding that to the configure line in the fedora package so far (note that timesyncd is very recent addition). Or in other words: nobody should really use google's servers in the distros. They should use their own pools. > 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... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
