On Tue, 26.08.14 15:56, Simon Peeters (peeters.si...@gmail.com) wrote: > > 2014-08-26 14:37 GMT+02:00 Lennart Poettering <lenn...@poettering.net>: > > On Tue, 26.08.14 16:34, Andrei Borzenkov (arvidj...@gmail.com) wrote: > > > >> > 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. > >> > >> What's wrong with having standard API for querying whether NTP is > >> enabled on a system? Is it better if every DE has to use home-grown > >> checks multiplied by number of NTP implementations? > > > > We are simply not in that business. I mean, we don't provide the same > > for HTTP implementations, FTP implementations, webdav implementations, > > and so on either... > > But we do for display managers, so maybe we can go the same way here: > - have al (s)ntp clients include Alias=timesync.service > - timedated uses timesync.service for: > - checking wether ntp is enabled. > - disabling ntp if requested. > - timedated still uses systemd-timesyncd.service to enable ntp. > > I think this achieves what both sides want here: > - it allows the admin to systemctl enable somentpd.service > - it is quiet minimal in changes with what we have now (except the > Alias part in all other ntp service files) > - it allows timedated to check and controll ntp even if an other ntp > server is used > (with the caveat that disable and then enable will result in > switching to systemd-timesyncd) > > just my 2c, if you think it is a good way to go, i'll be happy to write a > patch.
I am not too convinced about this idea, since the semantics are too different. I mean, timesyncd is something that actually can run in early boot which the implementations really can't. If we have a generic name for this then people might end up depending on it, which will usually work on timesyncd, but will have completely different semantics on other implementations... I think we should simply document for timedatectl that it controls timesyncd, so that people can easily find that. (Also, we currently don't allow disabling units via their alias, only via their main name, so it's not that easy...) Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
