Bug 1136905

Summary: timedated controls systemd-timesyncd instead of installed NTP service
Product: [Fedora] Fedora Reporter: Miroslav Lichvar <mlichvar>
Component: timedatexAssignee: Miroslav Lichvar <mlichvar>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: johannbg, keramidasceid, kevin, lnykryn, mcatanzaro+wrong-account-do-not-cc, mlichvar, msekleta, rjones, s, systemd-maint, tgunders, vpavlin, zbyszek, zing
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-01-29 09:50:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Miroslav Lichvar 2014-09-03 14:47:13 UTC
Description of problem:
Support for detection of installed NTP service via /usr/lib/systemd/ntp-units.d directory was removed in systemd-216 and timedated (used by timedatectl and GNOME time settings) now always enables or disables the systemd-timesyncd service even when the chronyd or ntpd service is installed on the system.

This means that in the default Fedora installation the NTP status in timedatectl and GNOME time settings is reported incorrectly and the chronyd service can't be disabled by timedatectl/GNOME. Enabling NTP stops chronyd and starts timesyncd, but after reboot chronyd will be running again.

A patch adding a configure option to set the service controlled by timedated, so we could at least set it to our default NTP service, is here:

http://lists.freedesktop.org/archives/systemd-devel/2014-August/022537.html

Upstream is apparently not interested in having this configurable and suggested to do this downstream. Please consider including that patch and add --with-ntp-service=chronyd.service to the configure command, or patch the timedated code directly with the following command so it's not necessary to rerun autoconf/automake:

sed -i 's|systemd-timesyncd.service|chronyd.service|' src/timedate/timedated.c

Version-Release number of selected component (if applicable):
systemd-216-3.fc22

Comment 1 Michael Catanzaro 2014-09-29 13:33:12 UTC
I've started a thread for this issue at https://lists.fedoraproject.org/pipermail/desktop/2014-September/010749.html

Comment 2 Miroslav Lichvar 2014-11-21 14:42:32 UTC
Fedora now includes timedatex, an alternative implementation of the timedate D-Bus interface. It takes the names of the controlled NTP units from /usr/lib/systemd/ntp-units.d, similarly to what systemd-timedated did before version 216.

If the systemd maintainers don't want to deviate from upstream, I think this bug can be closed.

Comment 3 Michael Catanzaro 2014-11-21 15:58:29 UTC
Well we need to figure out how to integrate this into Fedora Workstation; in particular, surely we must ensure that the original systemd timedated and timedatectl are not installed (and they're currently not in any subpackage), and that timedatex is.

Comment 4 Miroslav Lichvar 2014-11-21 16:45:41 UTC
There is no conflict, timedatectl and systemd-timedated can remain in the systemd package. (although it would be nice to have subpackages for the various systemd components)

When timedatex is installed and enabled, it takes over the org.freedesktop.timedate1 bus name from systemd-timedated, its symlink in /etc/systemd/system has a higher priority.

timedatectl is compatible with timedatex, no need to remove it.

We just need to install timedatex. It could be a dependency of NTP packages that have a file in /usr/lib/systemd/ntp-units.d, or it could be installed independently to allow users to remove timedatex and keep the NTP packages. I'm not sure how useful that would be. What do you think?

Comment 5 Michael Catanzaro 2014-11-21 17:49:01 UTC
NTP packages that have a file in /usr/lib/systemd/ntp-units.d should Require timedatex, since you would almost always want it to be controllable if it's installed. When/if weak dependencies are approved, a Recommends would be more appropriate, so that sysadmins can remove timedatex if really desired.

Great that this was so easy to get working!

Comment 6 Miroslav Lichvar 2014-11-24 13:42:55 UTC
Ok. Before we do that, should we submit a self contained change and wait for an approval?

Comment 7 Michael Catanzaro 2014-11-24 16:04:10 UTC
Hm, I'm not sure if the change process is appropriate for this, since a change can be rejected, which means that "do nothing" should be an acceptable result. But in this case the status quo is not acceptable; we really need to either:

a) Use timedatex, or
b) Drop chrony

either of which would be a change, and both of which may be moderately controversial.

Regardless: if you have chrony installed, you also want timedatex, so the Requires is appropriate whether we go with timedatex/chrony or timedated/timesyncd. (Moreover: it would be unacceptable for Workstation users who already have chrony to not get timedatex, unless chrony were to somehow be automatically removed.) The Requires really is a good idea no matter what.

The real choice is not whether timedatex should be installed with chrony, but whether chrony should be installed at all. So I would probably just add the Requires and announce the change, and let the working groups decide for themselves whether to drop chrony or not. You could also make the change proposal "install timedatex by default" with the fallback plan "stop installing chrony by default so that timedatex is no longer installed." (But the working groups do get to decide what's installed by default in each product, so conceivably Server could go with chrony and Workstation could go with timesyncd, or vice-versa... another reason the global change process might not work well for this.)

Comment 8 Tom Gundersen 2014-11-30 13:41:44 UTC
I have no opinion of timedatex. I just want to comment on #7 and say that it is perfectly possible (and recommended by systemd upstream) to use chrony on a regular systemd system. It can be controlled by systemctl like any other system service.

If you prefer to do somtehing else that is fine, but you shuold at least be aware that there is a third option:

c) use chrony without timedatex, which will work as it did when timedated did not exist or did not have the ntp dropping support. In other words, just fine.

Comment 9 Michael Catanzaro 2014-11-30 15:52:35 UTC
(In reply to Tom Gundersen from comment #8)
> c) use chrony without timedatex, which will work as it did when timedated
> did not exist or did not have the ntp dropping support. In other words, just
> fine.

For cli users, sure, but for Fedora Workstation, this isn't a great solution because we would strongly prefer for GNOME to continue using the timedated D-Bus API, which is quite nice. We'd almost surely drop chrony if it isn't controllable via timedated/timedatex.

Comment 10 Kevin Kofler 2014-11-30 17:24:15 UTC
Since it's really GNOME which needs to be able to control chrony through timedated, how about you just add the Requires: timedatex to gnome-control-center?

And also, why is this not a blocker for F21? Is working time setting not in the blocker criteria?

Comment 11 Michael Catanzaro 2014-11-30 18:47:33 UTC
(In reply to Kevin Kofler from comment #10)
> Since it's really GNOME which needs to be able to control chrony through
> timedated, how about you just add the Requires: timedatex to
> gnome-control-center?

That's certainly a reasonable alternative.

(In weak dependency world, a Supplements would work better, to pull in timedatex only if chrony is installed.)

> And also, why is this not a blocker for F21? Is working time setting not in
> the blocker criteria?

timedated in F21 is still compatible with chrony; this change is only needed for F22 and beyond.

Comment 12 Michael Catanzaro 2014-11-30 18:51:45 UTC
(In reply to Michael Catanzaro from comment #11)
> (In weak dependency world, a Supplements would work better, to pull in
> timedatex only if chrony is installed.)

Sorry: this sentence did not make sense.

Comment 13 Kevin Kofler 2014-11-30 23:04:08 UTC
Actually, if boolean dependencies ever get implemented, you would be able to write:
Supplements: gnome-control-center and chrony
in timedatex. But last I checked, boolean dependencies were still only a proposed spec that was not implemented.

Comment 14 Miroslav Lichvar 2014-12-01 13:46:01 UTC
(In reply to Kevin Kofler from comment #10)
> Since it's really GNOME which needs to be able to control chrony through
> timedated, how about you just add the Requires: timedatex to
> gnome-control-center?

gnome-control-center is not the only timedate client, there is also the timedatectl utility, so systemd would need to depend on timedatex too if we wanted timedatectl to still work with chronyd/ntpd when gnome-control-center is not installed.

There is a case that wasn't addressed yet. When timedatex is installed and chronyd/ntpd is not, should timedatex control systemd-timesyncd? Currently, nothing adds a file for timesyncd to /usr/lib/systemd/ntp-units.d.

Comment 15 Miroslav Lichvar 2015-01-29 09:50:59 UTC
The chrony and ntp package now require timedatex.

https://fedorahosted.org/fesco/ticket/1394