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

[Lennart Poettering]

On Tue, 26.08.14 15:56, Simon Peeters (peeters.simon at gmail.com) wrote:

> 
> 2014-08-26 14:37 GMT+02:00 Lennart Poettering <lennart at poettering.net>:
> > On Tue, 26.08.14 16:34, Andrei Borzenkov (arvidjaar at 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