Red Hat Bugzilla – Bug 858795
kcm_clock: add systemd timedated support
Last modified: 2015-07-13 04:12:01 EDT
instead of calling ntpdate or rdate directly, add support for using systemd timedated service as outlined here:
Looks like this is the cli way:
qdbus --system org.freedesktop.timedate1 /org/freedesktop/timedate1 \
org.freedesktop.timedate1.SetNTP 1 1
shouldn't be too hard to hook into that in the code.
Oh, and see also bug #816752 "systemd v28 changes indirectly break date and ntpdate"
The right way to handle this would be using QtDBus, not spawning qdbus through KProcess or QProcess. Also, the KDE-specific KAuth mechanism for kcm_clock should then go away entirely, because systemd already handles the PolicyKit stuff. Basically all the backend code of kcm_clock can be thrown away in favor of systemd's implementation.
This is also somewhat related to bug #829881 because we'd be using the org.freedesktop.timedate1.* policies instead of the org.kde.kcontrol.kcmclock.save one (assuming we implement this correctly – again, just spawning qdbus as root instead of ntpdate in the existing kcm_clock mechanism is NOT the correct way, the point of the systemd service is that it handles everything including the polkit stuff).
Aye, let's see :)
So, after having the prototype code ready and working, I, however, decided not to go this way for several reasons:
1. the current KAuth code works fine and we'd have to keep it anyway, either for compatibility reasons or for people who decide to disable systemd-timedated which would result in code bloat, not reduction
2. systemd-timedated doesn't correctly read the timezone back, if you set it by the traditional means (like using date(1) or tzset(3))
3. systemd-timedated has distinct methods for changing datetime, timezone and ntp preference, however, each of these methods invokes polkit in the background, resulting in 3 (!) auth dialogs presented to the user in consecution when confirming the KDE date/time control dialog
4. systemd-timedated lacks a signal telling us the date/time/timezone have been indeed changed