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.
Related ntp bug is bug 821820.
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.
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.
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.
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.
BTW, it is not mandatory to have the whole Base group installed. yum upgrade instructions are just recommendations.
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(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?
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
anaconda team states that anaconda does not reinstall @base on upgrade, so no, anaconda would not reinstall chrony.
(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.
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
(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.
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.
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.
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.
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!
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.
timedated in F18 now controls chronyd.service/ntpd.service directly. This should resolve the problem.
systemd-190-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/systemd-190-1.fc18
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).
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).
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).
(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.
*** Bug 821820 has been marked as a duplicate of this bug. ***
(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.