Bug 906854 - kcmdatetimehelper can't find zic nor hwclock, can't set timezone from within KDE if /etc/localtime doesn't exist yet
Summary: kcmdatetimehelper can't find zic nor hwclock, can't set timezone from within ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kde-workspace
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kevin Kofler
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-02-01 17:33 UTC by Patrick O'Callaghan
Modified: 2013-02-10 04:41 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 906972 (view as bug list)
Environment:
Last Closed: 2013-02-05 03:08:42 UTC


Attachments (Terms of Use)

Description Patrick O'Callaghan 2013-02-01 17:33:43 UTC
Description of problem:
Attempting to set the timezone from System Settings widget in KDE gives an error message.

Version-Release number of selected component (if applicable):
kde-settings-4.9-16.fc18.1.noarch

How reproducible:
100%

Steps to Reproduce:
1.Visit System Settings->System Administration->Date & Time
2.Click on the Time Zone tab
3.Select a timezone different from the default (UTC in my case) and hit Apply.
 
Actual results:
Popup error saying "Error setting new time zone."

Expected results:
Changed system time zone.

Additional info:
Same applies when right-clicking on the calendar panel widget and selecting Adjust Date & Time. Problem is independent of SELinux settings. It's noticeable that no authentication password is requested after hitting Apply.

Comment 1 Rex Dieter 2013-02-01 18:06:10 UTC
/usr/share/polkit-1/rules.d/11-fedora-kde-policy.rule

// kde-settings authorizations/policy for the wheel group.
//
// DO NOT EDIT THIS FILE, it will be overwritten on update.
//
// Allow users in the wheel group to do set the clock in kcm_clock without being
// interrupted by a password dialog

polkit.addRule(function(action, subject) {
    if (action.id == "org.kde.kcontrol.kcmclock.save" &&
        subject.isInGroup("wheel") && subject.active) {
        return polkit.Result.YES;
    }
});

in short, means admin/wheel users aren't prompted for root auth.

Now, why it's not working is indeed a bug, probably time (pun!) to adapt to using systemd method(s) for setting timezone at least.

Comment 2 Patrick O'Callaghan 2013-02-01 18:45:41 UTC
(In reply to comment #1)
> /usr/share/polkit-1/rules.d/11-fedora-kde-policy.rule
> 
> // kde-settings authorizations/policy for the wheel group.
> //
> // DO NOT EDIT THIS FILE, it will be overwritten on update.
> //
> // Allow users in the wheel group to do set the clock in kcm_clock without
> being
> // interrupted by a password dialog
> 
> polkit.addRule(function(action, subject) {
>     if (action.id == "org.kde.kcontrol.kcmclock.save" &&
>         subject.isInGroup("wheel") && subject.active) {
>         return polkit.Result.YES;
>     }
> });
> 
> in short, means admin/wheel users aren't prompted for root auth.

OK, I am in the wheel group so that part is fine.

> Now, why it's not working is indeed a bug, probably time (pun!) to adapt to
> using systemd method(s) for setting timezone at least.

Could be. I'm surprised no-one has reported this before now but I guess changing the timezone after installation isn't a common operation.

Comment 3 Kevin Kofler 2013-02-01 23:11:13 UTC
The offending code is here:
https://projects.kde.org/projects/kde/kde-workspace/repository/entry/kcontrol/dateandtime/helper.cpp?rev=KDE%2F4.9#L173

So this tries invoking "zic" if it's found, otherwise it tries deleting "/etc/localtime" and copying "/usr/share/zoneinfo/" + selected_zone to "/etc/localtime". An error can only be flagged if zic doesn't exist and the operation on /etc/localtime fails, there's no error checking at all in the zic case. glibc-common ships /usr/sbin/zic: http://koji.fedoraproject.org/koji/rpminfo?rpmID=3568832 so why would that not be found?

Comment 4 Kevin Kofler 2013-02-01 23:16:33 UTC
Can anybody else reproduce this? If so, I wonder whether changing "zic" to "/usr/sbin/zic" (i.e. hardcoding the path) would fix it.

Comment 5 Kevin Kofler 2013-02-01 23:18:28 UTC
By the way, hwclock is also in /usr/sbin, so invoking hwclock likely also fails if invoking zic fails, which unfortunately does not report an error, but fail silently. :-( (That would explain why people have been reporting lately that the hardware clock isn't getting updated anymore yet again, grrr…)

Comment 6 Patrick O'Callaghan 2013-02-01 23:58:50 UTC
(In reply to comment #3)
> The offending code is here:
> https://projects.kde.org/projects/kde/kde-workspace/repository/entry/
> kcontrol/dateandtime/helper.cpp?rev=KDE%2F4.9#L173
> 
> So this tries invoking "zic" if it's found, otherwise it tries deleting
> "/etc/localtime" and copying "/usr/share/zoneinfo/" + selected_zone to
> "/etc/localtime". An error can only be flagged if zic doesn't exist and the
> operation on /etc/localtime fails, there's no error checking at all in the
> zic case. glibc-common ships /usr/sbin/zic:
> http://koji.fedoraproject.org/koji/rpminfo?rpmID=3568832 so why would that
> not be found?

I tried running zic from the Shell:

$ zic /usr/share/zoneinfo/America/Caracas 
"/usr/share/zoneinfo/America/Caracas", line 1: line too long
$ zic /usr/share/zoneinfo/America/New_York 
"/usr/share/zoneinfo/America/New_York", line 1: line too long
$ zic /usr/share/zoneinfo/America/Chicago 
"/usr/share/zoneinfo/America/Chicago", line 1: line too long

so it looks like the problem is with the zoneinfo files. I tried reinstalling tzdata (tzdata-2012j-1.fc18.noarch) but it made no difference. There isn't a more recent version of tzdata even on koji.

However I'm confused by something here. Doesn't zic take a textual description of zone info and produce a binary zoneinfo file? The reason I ask is that the contents of /usr/share/zoneinfo are binary files, presumably the output of zic rather than the input to it.

Comment 7 Kevin Kofler 2013-02-02 00:23:01 UTC
So, the bad news is that this has been broken since AT LEAST Fedora 16 (!). What changed is that F18 apparently doesn't install an /etc/localtime anymore for UTC, so deleting the file fails (at least I think that's what's going on), which uncovers the whole fiasco. Ouch!

We should fix this in all supported Fedora releases, this is all the more important for hwclock. (I wonder if and how the hwclock-invoking code ever worked.)

Comment 8 Kevin Kofler 2013-02-02 00:23:58 UTC
Re comment #6, zic should be invoked as:
zic -l America/Caracas
and that's how kcm_clock invokes it if it finds it.

Comment 9 Kevin Kofler 2013-02-02 01:12:56 UTC
I think I have a fix, there should be a build which fixes this in a few hours.

Comment 10 Kevin Kofler 2013-02-02 01:59:30 UTC
Oh, and please DON'T run zic manually before testing the fix, you might not be able to reproduce (the user-visible part of) the bug if you do. (FYI, I THINK the condition for the error message to show up is that /etc/localtime doesn't exist.)

Comment 11 Kevin Kofler 2013-02-02 02:43:04 UTC
Can you please test:
http://koji.fedoraproject.org/koji/taskinfo?taskID=4923179
?

Comment 12 Patrick O'Callaghan 2013-02-02 05:04:46 UTC
(In reply to comment #11)
> Can you please test:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=4923179
> ?

Nearly but not quite. The changes now execute without error (checked by running 'date' from a Shell while the dialogue is still open), but when I exit the dialoque it asks if I want to Apply or Discard the change. Hitting Apply causes the change to revert to UTC. I didn't check what Discard does.

Comment 13 Kevin Kofler 2013-02-02 05:51:22 UTC
Hmmm, can you please check what time zone is selected in the dialog after you select your timezone and click Apply, but before you exit the dialog? I suspect it is jumping back to UTC, which in turn makes it ask you whether to apply or discard the change which reverts the timezone to UTC (i.e. Discard is actually what you want then).

If I'm right and that's what happening, then the problem must be when the dialog reloads the time information using Dtime::load(). That function uses KSystemTimeZones::local() to determine the current time zone, somehow that must be returning wrong or outdated information.

Comment 14 Kevin Kofler 2013-02-02 06:03:23 UTC
This is another bug, in ktimezoned:

https://projects.kde.org/projects/kde/kde-runtime/repository/revisions/master/entry/ktimezoned/ktimezoned.cpp#L337

It will only watch for changes to /etc/localtime if the file already existed. So if the file was not there and it gets created, nothing happens.

Comment 15 Kevin Kofler 2013-02-02 06:07:44 UTC
See bug #906972 for the new issue.

Comment 16 Rex Dieter 2013-02-02 14:09:11 UTC
Thanks Kevin!

Longer term, looks like systemd may actually bring a lot of simplifications our way.  I'll look into implementing support for timedatectl too sometime soon (hopefully).

$ timedatectl --help
timedatectl [OPTIONS...] COMMAND ...

Query or change system time and date settings.

  -h --help              Show this help
     --version           Show package version
     --adjust-system-clock
                         Adjust system clock when changing local RTC mode
     --no-pager          Do not pipe output into a pager
     --no-ask-password   Do not prompt for password
  -H --host=[USER@]HOST  Operate on remote host

Commands:
  status                 Show current time settings
  set-time TIME          Set system time
  set-timezone ZONE      Set system timezone
  list-timezones         Show known timezones
  set-local-rtc BOOL     Control whether RTC is in local time
  set-ntp BOOL           Control whether NTP is enabled

Comment 17 Patrick O'Callaghan 2013-02-02 14:29:48 UTC
(In reply to comment #13)
> Hmmm, can you please check what time zone is selected in the dialog after
> you select your timezone and click Apply, but before you exit the dialog? I
> suspect it is jumping back to UTC, which in turn makes it ask you whether to
> apply or discard the change which reverts the timezone to UTC (i.e. Discard
> is actually what you want then).
> 
> If I'm right and that's what happening, then the problem must be when the
> dialog reloads the time information using Dtime::load(). That function uses
> KSystemTimeZones::local() to determine the current time zone, somehow that
> must be returning wrong or outdated information.

Well spotted, that's exactly what is happening. After selecting the new timezone the dialogue box whites out and when it comes back I find UTC is still selected, even though 'date' shows the new timezone.

Comment 18 Patrick O'Callaghan 2013-02-02 14:50:56 UTC
(In reply to comment #16)
> Thanks Kevin!
> 
> Longer term, looks like systemd may actually bring a lot of simplifications
> our way.  I'll look into implementing support for timedatectl too sometime
> soon (hopefully).
> 
> $ timedatectl --help
> timedatectl [OPTIONS...] COMMAND ...
> 
> Query or change system time and date settings.
> 
>   -h --help              Show this help
>      --version           Show package version
>      --adjust-system-clock
>                          Adjust system clock when changing local RTC mode
>      --no-pager          Do not pipe output into a pager
>      --no-ask-password   Do not prompt for password
>   -H --host=[USER@]HOST  Operate on remote host
> 
> Commands:
>   status                 Show current time settings
>   set-time TIME          Set system time
>   set-timezone ZONE      Set system timezone
>   list-timezones         Show known timezones
>   set-local-rtc BOOL     Control whether RTC is in local time
>   set-ntp BOOL           Control whether NTP is enabled

When I use timedatectl to set the timezone, the Settings dialogue still thinks it's UTC. This is liable to cause problems down the road.

Comment 19 Rex Dieter 2013-02-02 15:10:40 UTC
sure, I believe your findings are part of bug #906972 (kde not properly noticing/detecting the currently configured time zone)

Comment 20 Kevin Kofler 2013-02-02 18:27:35 UTC
The patch for this bug passed upstream review:
https://git.reviewboard.kde.org/r/108711/

I'm committing it to upstream master now, and the upstream 4.10 branch as soon as the tagging freeze is lifted. (I don't think a longstanding bug like this qualifies for a freeze exemption.)

Comment 21 Kevin Kofler 2013-02-02 18:38:25 UTC
Actually, seeing upstream's kde-workspace git history, I'm probably supposed to commit to 4.10 first and then merge 4.10 into master, so I'll rather do it that way, after the freeze is lifted.

Comment 22 Kevin Kofler 2013-02-02 19:04:59 UTC
Re using timedatectl: ltinkl looked into that at some point (well, actually the underlying D-Bus API), and found the API to be lacking. In particular, there is no one API to set everything (NTP, time zone, time), so you end up getting prompted for PolicyKit authentication 3 times!

Comment 23 Kevin Kofler 2013-02-02 19:07:00 UTC
Oh, and of course, it'd be possible to work around it by running timedatectl (or using the D-Bus API) as root, but then we still need the KAuth helper and we just add one more code path to it, which ltinkl didn't see as a win.

Comment 24 Fedora Update System 2013-02-03 04:42:53 UTC
libkscreen-0.0.71-2.fc18, kscreen-0.0.71-3.fc18, kde-settings-4.9-19.fc18, kde-workspace-4.9.5-7.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/FEDORA-2013-1183/kde-settings-4.9-19.fc18,kde-workspace-4.9.5-7.fc18,libkscreen-0.0.71-2.fc18,kscreen-0.0.71-3.fc18

Comment 25 Fedora Update System 2013-02-03 04:45:36 UTC
libkscreen-0.0.71-2.fc17, kscreen-0.0.71-3.fc17, kde-settings-4.8-24.fc17, kde-workspace-4.9.5-7.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/FEDORA-2013-1248/kde-settings-4.8-24.fc17,kde-workspace-4.9.5-7.fc17,kscreen-0.0.71-3.fc17,libkscreen-0.0.71-2.fc17

Comment 26 Fedora Update System 2013-02-03 04:52:36 UTC
kde-workspace-4.8.5-3.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/kde-workspace-4.8.5-3.fc16

Comment 27 Fedora Update System 2013-02-05 03:06:35 UTC
Package libkscreen-0.0.71-2.fc17, kscreen-0.0.71-3.fc17, kde-settings-4.8-24.fc17, kde-workspace-4.9.5-7.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libkscreen-0.0.71-2.fc17 kscreen-0.0.71-3.fc17 kde-settings-4.8-24.fc17 kde-workspace-4.9.5-7.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-1248/kde-settings-4.8-24.fc17,kde-workspace-4.9.5-7.fc17,kscreen-0.0.71-3.fc17,libkscreen-0.0.71-2.fc17
then log in and leave karma (feedback).

Comment 28 Fedora Update System 2013-02-05 03:08:44 UTC
libkscreen-0.0.71-2.fc18, kscreen-0.0.71-3.fc18, kde-settings-4.9-19.fc18, kde-workspace-4.9.5-7.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 29 Fedora Update System 2013-02-05 17:05:01 UTC
libkscreen-0.0.71-2.fc17, kscreen-0.0.71-3.fc17, kde-settings-4.8-24.fc17, kde-workspace-4.9.5-7.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 30 Fedora Update System 2013-02-10 04:41:58 UTC
kde-workspace-4.8.5-3.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.


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