Bug 870535 - Regression in handling of localtime RTC: timezone offset applied twice
Summary: Regression in handling of localtime RTC: timezone offset applied twice
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 18
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F18systemd
TreeView+ depends on / blocked
 
Reported: 2012-10-26 18:42 UTC by Michel Lind
Modified: 2012-12-08 04:36 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-12-08 04:36:01 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
dmesg, localtime and adjtime showing incorrect localtime (998 bytes, application/octet-stream)
2012-10-26 18:42 UTC, Michel Lind
no flags Details
Patch to systemd F18 branch to apply Kay's git commit (4.83 KB, patch)
2012-11-01 17:19 UTC, Michel Lind
no flags Details | Diff

Description Michel Lind 2012-10-26 18:42:26 UTC
Created attachment 634008 [details]
dmesg, localtime and adjtime showing incorrect localtime

Description of problem:
On a fully updated Fedora 18 system, after booting to Windows and back I noticed that the system clock is offset by an additional seven hours (from UTC+7 to effectively UTC+14).

I have tried reinstalling Fedora 17, verifying that hwclock and date agree with each other, before then upgrading again to Fedora 18 using yum, and the issue persists.

Version-Release number of selected component (if applicable):
systemd-194-1.fc18.x86_64
systemd-195-4.fc18.x86_64 (from Koji)
kernel-3.6.2-2.fc18.x86_64


How reproducible:
Always

Steps to Reproduce:
1. Install Fedora 17, specifying HW clock is *not* set to UTC
2. Verify clock is correct
3. Update to Fedora 18
  
Actual results:
System clock is incorrect; see attached typescript for dmesg, localtime and adjtime settings. Note that the script was generated ~ 1 AM local time, *not* 8 AM as indicated.

Expected results:
Local time support should work without having to do hwclock --hctosys by hand.

Additional info:

Comment 1 Kay Sievers 2012-10-27 12:13:33 UTC
I guess we move it in the wrong direction in 195.
Can you please paste the output of:

$ timedatectl 
      Local time: Sat, 2012-10-27 13:58:59 CEST
  Universal time: Sat, 2012-10-27 11:58:59 UTC
        RTC time: Sat, 2012-10-27 11:58:58
        Timezone: Europe/Berlin
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no

Thanks!

Comment 2 Kay Sievers 2012-10-27 14:32:54 UTC
I suspect systemd in dracut seals the kernel's time-warp, which we expect to
work in the real system. This might fix it:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=19e65613563dd9c14cf1ce58aa6e151de8fb90c2

Comment 3 Michel Lind 2012-10-28 03:22:26 UTC
Certainly (and it happened with 194 too, I actually downloaded 195 from Koji to test if that fixed it). Will that commit be in 196?

✗ timedatectl 
      Local time: Sun, 2012-10-28 10:21:25 WIT
  Universal time: Sun, 2012-10-28 03:21:25 UTC
        RTC time: Sun, 2012-10-28 10:21:25
        Timezone: Asia/Jakarta
     NTP enabled: yes
NTP synchronized: no
 RTC in local TZ: yes

Warning: The RTC is configured to maintain time in the local time zone. This
         mode is not fully supported and will create various problems with time
         zone changes and daylight saving adjustments. If at all possible use
         RTC in UTC, by calling 'timedatectl set-local-rtc 0'.

Comment 4 Michel Lind 2012-10-28 03:24:25 UTC
(In reply to comment #3)
> ✗ timedatectl 
>       Local time: Sun, 2012-10-28 10:21:25 WIT
>   Universal time: Sun, 2012-10-28 03:21:25 UTC
>         RTC time: Sun, 2012-10-28 10:21:25

This is after manually running hwclock --hctosys, but I take it you just want to verify that timezone, NTP enabled/synchronized/localTZ is set properly.

NTP is not synchronized because my horrible, horrible cable provider *blocked* ports 123 on their clients' machines, and the only way to get NTP sync working is to run ntpdate as a client with a port >= 1024, which I've not figured out how to get chrony to do

Comment 5 Miroslav Lichvar 2012-10-29 10:41:27 UTC
(In reply to comment #4)
> NTP is not synchronized because my horrible, horrible cable provider
> *blocked* ports 123 on their clients' machines, and the only way to get NTP
> sync working is to run ntpdate as a client with a port >= 1024, which I've
> not figured out how to get chrony to do

You can try adding "port 11123" to chrony.conf.

Comment 6 Lennart Poettering 2012-10-29 15:38:39 UTC
Given the fix in systemd git I presume this issue is fixed upstream now.

Comment 7 Michel Lind 2012-11-01 15:46:58 UTC
(In reply to comment #6)
> Given the fix in systemd git I presume this issue is fixed upstream now.

That patch sounds like it should fix the issue, but given that you announced that 196 will be targeting Fedora 19, perhaps the patch should be cherry-picked for a bugfix F18 update?

I could try doing that and see if that solves the problem. Presumably I'd need to run dracut and update my initrd as well.

(In reply to comment #5)
> (In reply to comment #4)
> > NTP is not synchronized because my horrible, horrible cable provider
> > *blocked* ports 123 on their clients' machines, and the only way to get NTP
> > sync working is to run ntpdate as a client with a port >= 1024, which I've
> > not figured out how to get chrony to do
> 
> You can try adding "port 11123" to chrony.conf.

As it turns out, I needed to tell SELinux about the port change (good thing there's the troubleshooter - though why semanage is so slow beats me).

The Chrony documentation probably should be updated to mention the "port N" configuration option.

Comment 8 Miroslav Lichvar 2012-11-01 16:13:46 UTC
(In reply to comment #7)
> The Chrony documentation probably should be updated to mention the "port N"
> configuration option.

It's listed in the "4.2 The chronyd configuration file" section in the chrony info document.

Comment 9 Michel Lind 2012-11-01 17:19:09 UTC
Created attachment 636748 [details]
Patch to systemd F18 branch to apply Kay's git commit

I just tested an updated systemd build for F18 (patch attached), and after rebuilding my initrd using dracut, it does seem the issue is fixed. Would be great to see this fix land post-beta!

@ Miroslav - oops, the info file is the one place I didn't look. Thanks!

Comment 10 Steve Tyler 2012-12-02 23:01:49 UTC
Could you do a build for F18 of systemd 196 or a build of 195 with a patch for this bug?

I am trying to sort out the problems involving the RTC on local time in this bug:
Bug 881403 - Anaconda doesn't correctly infer if system clock shows UTC or local time 

There appear to be at least two problems, but I can't tell for sure without a fix for this bug.

Comment 11 Fedora Update System 2012-12-05 17:32:15 UTC
systemd-195-10.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/systemd-195-10.fc18

Comment 12 Fedora Update System 2012-12-05 23:15:59 UTC
Package systemd-195-10.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-195-10.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-19811/systemd-195-10.fc18
then log in and leave karma (feedback).

Comment 13 Steve Tyler 2012-12-06 18:30:20 UTC
(In reply to comment #11)
> systemd-195-10.fc18 has been submitted as an update for Fedora 18.
> https://admin.fedoraproject.org/updates/systemd-195-10.fc18

Thanks. I have tested systemd-195-10.fc18 in a VM and on bare metal, and it seems to fix this bug.

As Michel noted[1], the initramfs needs to be rebuilt. This can be accomplished by updating the kernel after updating systemd.

Test procedure:

Set RTC to local time in BIOS.
Boot.
Set time zone.
Disable chronyd.
Verify that /etc/adjtime has LOCAL and not UTC.
Reboot.

Verify that the time returned by the date command matches the RTC:
$ date; cat /proc/driver/rtc

[1] Comment 9.

Comment 14 Fedora Update System 2012-12-08 04:36:04 UTC
systemd-195-10.fc18 has been pushed to the Fedora 18 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.