Bug 821813 - chronyd can't be disabled
chronyd can't be disabled
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
17
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs
: 821820 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-15 10:39 EDT by Jonathan Kamens
Modified: 2012-10-24 09:25 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-07 18:48:32 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jonathan Kamens 2012-05-15 10:39:52 EDT
I don't want to use chronyd with F17. I want to continue to use ntpd as I have always used.

So I did "systemctl disable chronyd.service; systemctl stop chronyd.service; systemctl enable ntpd.service; systemctl start ntpd.service", and ntpd started just fine.

Then I rebooted, and chronyd started and ntpd didn't.

I thought it was a fluke, so I did it all again. Once again, chronyd started and ntpd didn't.

When I now do "systemctl disable chronyd.service", it doesn't print anything. Ditto when I do "systemctl enable ntpd.service". Which means, as far as I can tell, that systemd thinks that chronyd is disabled and ntpd is enabled. So why is chronyd starting, and ntpd not starting, when I reboot?

The problem is this link, which is packaged in the RPM and therefore created when chrony is installed:

3670077    0 lrwxrwxrwx   1 root     root           18 Apr 29 22:12 /lib/systemd/system/systemd-timedated-ntp.target.wants/chronyd.service -> ../chronyd.service

There's a similar link for ntpd.

This should be created by a "WantedBy" line in the chronyd.service file rather than packaged in the RPM:

WantedBy=systemd-timedated-ntp.target

There is, incidentally, a similar problem with ntpd, about which I will file a separate bug report.

This makes it impossible to disable chronyd, which seems like a pretty serious problem with the new chronyd feature in F17.
Comment 1 Jonathan Kamens 2012-05-15 10:43:13 EDT
Related ntp bug is bug 821820.
Comment 2 Miroslav Lichvar 2012-05-15 10:49:21 EDT
That link was added to fix bug #816493. I don't fully understand why it's needed or if we can use the WantedBy directive instead.

In any case, a workaround should be to simply uninstall the chrony package.
Comment 3 Michal Schmidt 2012-05-15 11:36:35 EDT
The original idea is at https://bugzilla.redhat.com/show_bug.cgi?id=815748#c4

Let me explain what the original problem was:

Gnome ships a GUI tool that allows the user to configure whether he wants to have the system time synchronized from the network. In gnome-control-center there is a simple boolean switch labeled "Network Time". The switch is supposed to enable an NTP service. The implementation depends on a privileged service to perform the actual enabling/disabling action. That service is "systemd-timedated".

The question is: Which NTP service should systemd-timedated control? ntpd.service or chrony.service? It used to be hardcoded to ntpd.service. People were rightfully unhappy about this, because Fedora now ships chrony by default.

The chosen solution was to add an indirection. systemd-timedated now enables/disables systemd-timedated-ntp.target instead of a specific service. NTP services are expected to hook into this target.

Now if chronyd.service used a WantedBy in the '[Install]' section instead of shipping the symlink in the package, it would go against the original purpose for which the target was added. The GUI would stop working, because enabling the target with it would have no effect on chronyd.service.

You _can_ disable systemd-timedated-ntp.target.

I can see that it can be confusing, but I do not immediately see another solution.
Comment 4 Jonathan Kamens 2012-05-15 11:46:53 EDT
It's not "confusing". It's BROKEN. With chrony installed, you CAN'T USE NTPD, and chrony is now part of Base, which means that it's "supposed" to be installed on every Fedora system. I don't know if anaconda-based upgrades will reinstall it if it is removed (I suspect they will), but certainly upgrading with yum will, since the yum upgrade instructions say to do a "yum groupupdate Base" as part of the upgrade process.

The right solution is probably to use alternatives.
Comment 5 Michal Schmidt 2012-05-15 11:53:51 EDT
I wonder if using the "alternatives" mechanism to control a symlink called
/lib/systemd/system/systemd-timedated-ntp.service would help here. The symlink
would point to one or the other NTP implementation service.
By enabling/disabling systemd-timedated-ntp.service the systemd-timedated
daemon would really enable/disable the preferred NTP service directly.

I don't know enough about "alternatives" to know if there are any possible
issues with this.
Comment 6 Michal Schmidt 2012-05-15 11:55:45 EDT
BTW, it is not mandatory to have the whole Base group installed. yum upgrade instructions are just recommendations.
Comment 7 Adam Williamson 2012-05-15 11:56:16 EDT

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 8 Jonathan Kamens 2012-05-15 12:01:30 EDT
(In reply to comment #6)
> BTW, it is not mandatory to have the whole Base group installed. yum upgrade
> instructions are just recommendations.

That's a cop out.

1) You didn't address what an anaconda upgrade would do, and I'm pretty certain it would reinstall Chrony.

2) The "recommendations" made by the Fedora maintainers to users should work properly. The fact that it's just a "recommendation" doesn't mean it's allowed to be broken. How could it possibly make any sense for the maintainers to "recommend" something that breaks a user's system?
Comment 9 Adam Williamson 2012-05-15 12:08:24 EDT
Could you please stop sounding like the sky is falling? It's a minor bug with several known and documentable workarounds. Fedora contains several thousand of them; do note that this is bug #eight hundred thousand and something. So does any piece of software. We work to mitigate its impact then we try and figure out a way to fix it, and we move on. Your tone seems entirely inappropriate to the severity of the problem. It's hardly the case that any systems are being 'broken', as you claim. The worst possible impact of this bug is that a system doesn't get its time set over the network. That's not going to ruin anyone's day.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 10 Adam Williamson 2012-05-15 12:14:31 EDT
anaconda team states that anaconda does not reinstall @base on upgrade, so no, anaconda would not reinstall chrony.
Comment 11 Jonathan Kamens 2012-05-15 12:31:30 EDT
(In reply to comment #9)
> Could you please stop sounding like the sky is falling?

Fair enough.

I am not upset specifically about this bug, but rather about the fact that it is a manifestation of what I perceive as a much larger problem with Fedora, in particular the seemingly uncontrollable urge to introduce New Stuff[tm] without adequate attention to making sure that it doesn't break Old Stuff.

"Make sure people who want to can still use ntpd" should have been the very first test case when the decision was made to switch to chronyd.

I find this pattern disturbing because it does a disservice to users and because it hurts Fedora by causing an impression (which is IMO at least to some extent deserved) of poor quality.

I'm not sure I've used any other software product whose maintainers were so cavalier about breaking stuff in upgrades. This is just one of many, many examples of that.

But you're right that this discussion doesn't belong in a bug about one particular problem, so I'll stop preaching.
Comment 12 Adam Williamson 2012-05-15 12:41:36 EDT
As noted above, this is a rather more complex case than just 'switch to chronyd'. The issue isn't the switch, exactly, but the problem of how to handle the slider in the GNOME control center.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 13 Michal Schmidt 2012-05-23 08:42:23 EDT
(In reply to comment #5)
> I wonder if using the "alternatives" mechanism to control a symlink called
> /lib/systemd/system/systemd-timedated-ntp.service would help here. The
> symlink
> would point to one or the other NTP implementation service.

So with alternatives the symlinks would look like this:

/lib/systemd/system/systemd-timedated-ntp.service
-> /etc/alternatives/systemd-timedated-ntp.service
  -> /lib/systemd/system/chronyd.service

> By enabling/disabling systemd-timedated-ntp.service the systemd-timedated
> daemon would really enable/disable the preferred NTP service directly.

It wouldn't work exactly like this though, because systemctl enable/disable do not follow symlinks. This may be something to fix.
But we could easily have systemd-timedated resolve the symlink first and then enable/disable the final target.
Comment 14 Adam Williamson 2012-05-29 01:04:53 EDT
CommonBugs entry added. I've tried to document the various valid workarounds there, and describe the issue accurately. Michal, please let me know if I got anything wrong.
Comment 15 Michal Schmidt 2012-05-29 08:08:16 EDT
Due to ntpd.service's BindTo dependency on systemd-timedated-ntp.target, disabling the target may not be sufficient. So I modified the CommonBugs entry to recommend masking chronyd.service, which works in all cases.
Comment 16 Michal Schmidt 2012-06-07 03:57:38 EDT
Lennart did not like the alternatives proposal. He and I agreed to have systemd-timedated work with a list of well-known ntp services. The list will be in a file shipped with systemd-timedated.

When asked to disable "Network Time", systemd-timedated will disable all of the listed services. When asked to enable it, the services will be tried in order until one succeeds. systemd-timedated-ntp.target will be removed.

Reassigning to systemd. When we're ready, we'll ask Miroslav to update chrony and ntp and we'll probably make a grouped Bodhi update.
Comment 17 Jonathan Kamens 2012-06-07 22:39:26 EDT
Alternatives is _clearly_ the right technology for solving this problem. This kind of problem is _exactly_ what alternatives was meant for. It is completely incomprehensible to me why you would choose such a kludgy, clearly inferior solution.

(In reply to comment #16)
> When asked to disable "Network Time", systemd-timedated will disable all of
> the listed services. When asked to enable it, the services will be tried in
> order until one succeeds.

In what order?

If both chronyd and ntpd are installed, how will it know which one to use?

This is ludicrous. Really.

You're inventing unnecessary problems out of whole cloth. Just use alternatives!
Comment 18 stepglenn 2012-06-20 09:51:28 EDT
I simply un-installed chrony to get NTP to work correctly:

  yum erase chrony

This is not a fix, but it is a reliable work around.
Now ntpdate/ntpd/ntp-wait services all work correctly on a reboot.
Comment 19 Lennart Poettering 2012-09-14 10:20:23 EDT
timedated in F18 now controls chronyd.service/ntpd.service directly. This should resolve the problem.
Comment 20 Fedora Update System 2012-09-20 15:56:18 EDT
systemd-190-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/systemd-190-1.fc18
Comment 21 Fedora Update System 2012-09-22 02:37:27 EDT
Package systemd-191-2.fc18, rtkit-0.11-3.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-191-2.fc18 rtkit-0.11-3.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-14581/rtkit-0.11-3.fc18,systemd-191-2.fc18
then log in and leave karma (feedback).
Comment 22 Fedora Update System 2012-09-27 20:17:53 EDT
Package glibc-2.16-17.fc18, systemd-192-1.fc18, selinux-policy-3.11.1-23.fc18, rtkit-0.11-3.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing glibc-2.16-17.fc18 systemd-192-1.fc18 selinux-policy-3.11.1-23.fc18 rtkit-0.11-3.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-14581/selinux-policy-3.11.1-23.fc18,rtkit-0.11-3.fc18,systemd-192-1.fc18,glibc-2.16-17.fc18
then log in and leave karma (feedback).
Comment 23 Fedora Update System 2012-10-01 16:10:26 EDT
Package glibc-2.16-17.fc18, rtkit-0.11-3.fc18, systemd-193-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing glibc-2.16-17.fc18 rtkit-0.11-3.fc18 systemd-193-1.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-14581/rtkit-0.11-3.fc18,systemd-193-1.fc18,glibc-2.16-17.fc18
then log in and leave karma (feedback).
Comment 24 Frank Crawford 2012-10-07 03:05:32 EDT
(In reply to comment #18)

A simpler solution for F17 is to remove the symlink

/lib/systemd/system/systemd-timedated-ntp.target.wants/chronyd.service

although this will probably be recreated with any chronyd update.
Comment 25 Miroslav Lichvar 2012-10-23 11:39:23 EDT
*** Bug 821820 has been marked as a duplicate of this bug. ***
Comment 26 Michal Schmidt 2012-10-24 09:25:34 EDT
(Re: comment #24: Editing/deleting files under /lib is a bad idea.)

The Common F17 Bugs page lists two valid workarounds:

  If you wish to prevent chronyd from starting, you can do
  systemctl mask chronyd.service
  Or, you can remove the chrony package.


For F17 this is probably as good as it gets. Although backporting F18's solution is conceivable, there would be some risk of breakage that I'm not willing to take.

Note You need to log in before you can comment on or make changes to this bug.