Description of problem: Since the change from Daylight Saving Time to the CET I see that Fedora starts with clock set to the old timezone (+2 UTC) and change to CET when I'm already entered in the desktop environment (KDE). If I reboot the PC I can see that in BIOS the change of time is not saved. When Fedora starts some services are not happy with the clock being turned backwards. For instance in BOINC I can see in the logs: mer 02 nov 2011 18:57:25 CET | | System clock was turned backwards; clearing timeouts And it blocks computations for an hour. Version-Release number of selected component (if applicable): cronie-1.4.8-10.fc16.x86_64 How reproducible: Always Steps to Reproduce: 1. Set the clock to 18.00 when in DST 2. Change the date to be no more in DST 3. Reboot the PC: you enter the desktop environment with 18.00 and after some second it changes to 17.00 Actual results: New time not saved in BIOS Expected results: Time saved in BIOS or change before other services starts
I don't see how this is related to cronie. Did you mentioned chrony? Time could be automatically set be chrony or ntpdate, which override your KDE settings.
Yes, sorry... I was just adding the note that I think I set the wrong component. Looking in /var/log/messages I can see chrony. Can you reassign the bug, please? Thank you chrony-1.26-3.20110831gitb088b7.fc16.x86_64
Created attachment 531402 [details] output of /var/log/messages
NTP doesn't know anything about timezones. This looks like RTC is in local time and hwclock --systohc is not called on shutdown/reboot. I'm not sure what is supposed to do that nowadays, let's try systemd.
It's probably this: https://bugzilla.redhat.com/show_bug.cgi?id=749516#c25
Interesting. What system component is supposed to monitor changes in DST and sync the RTC if it's on local time? Or is now only RTC on UTC supported? I like the idea of not doing the sync on shutdown as it allows chrony to track the RTC drift and correct it on boot.
Having the RTC in local time is broken in many ways and exists only for compatibility with Windows. If enabled, for summer time changes only one OS can be in charge, since the OS has to remember that it did the summer time change, in order not to repeat the adjustment on subsequent boots. Since the only use of this feature is compatibility with Windows anyway, that one OS in charge should be Windows, and not us. hence we are doing exactly the right thing here: leave the RTC completely untouched, and let Windows do its work. Or with other words: you can choose between a) automatic timezone changes from Linux and b) compatibility with Windows, but not have both. For a) enable UTC RTC time. For b) enable LOCAL RTC time. if you choose b) then it's Windows' job to change the summer time.
What's the problem _on a system using NTP_ to sync the RTC clock on boot if the DST changed recently and "surprisingly" the time obtained from NTP differs from the RTC clock time by one hour?
(In reply to comment #8) > What's the problem _on a system using NTP_ to sync the RTC clock on boot > if the DST changed recently and "surprisingly" the time obtained from > NTP differs from the RTC clock time by one hour? On NTP systems, the kernel automatically syncs to the RTC every 11 minutes.
Apparently that is not happening on the reporter's system.
(In reply to comment #9) > On NTP systems, the kernel automatically syncs to the RTC every 11 minutes. In the 11 minute mode kernel syncs only within 30 minutes as it doesn't know about timezones or DST. Chrony can be configured to track the RTC (the 11 minute mode is disabled) and RTC can be synced by the "chronyc trimrtc" command, but nothing else should be touching the RTC which is hard to guarantee.
> In the 11 minute mode kernel syncs only within 30 minutes as it doesn't know > about timezones or DST. Those like me, who did not know about this, see the kernel function: http://lxr.linux.no/#linux+v3.1/arch/x86/kernel/rtc.c#L41
(In reply to comment #11) > (In reply to comment #9) > > On NTP systems, the kernel automatically syncs to the RTC every 11 minutes. > > In the 11 minute mode kernel syncs only within 30 minutes as it doesn't know > about timezones or DST. Just FYI, some rare zones actually shift their DST time only by 0:30. Currently it's only Lord Howe Island in Australia, a couple more such zone existed at various points in the past.
Reopening. As this is clear regression. And no nobody wants to fix unfixable problems just please do not break things that worked before fine. If this sync should be done by chrony now let's be it.
That's not right, it never worked properly in dual OS boot environments. We did not break anything that was working, we just don't pretend we can solve that problem.
Yes, it never worked _fully_ correctly as this is not possible without cooperation with Windows. But it worked at least partially correctly on machines that are only occasionally booted into Windows. And this is now broken.
It depends on which detail you focus. I would state it's much less broken now than it was. It's just unfixable, so we should not try to pretend we know how it's used, and leave it alone instead of breaking things in the intention to make stuff working.
The issue is KDE not syncing the change to the hardware clock when the time is set in KDE? That's already being fixed. What else is wanted here?
(In reply to comment #18) > The issue is KDE not syncing the change to the hardware clock when the time is > set in KDE? That's already being fixed. What else is wanted here? This is not related to KDE (and to the other bug pointed out from Kay Sievers). After the change from DST to no DST I can see my system doing: 1. Boot Fedora and all services 2. Start chronyd and sync the clock with ntp: Nov 3 19:41:57 Betelgeuse chronyd[1050]: Selected source 93.62.230.241 Nov 3 19:41:57 Betelgeuse chronyd[1050]: System clock wrong by -3599.169419 seconds, adjustment started Nov 3 18:41:58 Betelgeuse chronyd[1050]: System clock was stepped by -3599.169 seconds 3. Some service (the most important is sendmail) don't react well to this Nov 3 18:42:55 Betelgeuse systemd[1]: sendmail.service operation timed out. Terminating. Nov 3 18:42:55 Betelgeuse systemd[1]: Unit sendmail.service entered failed state. 4. The new time is not saved to BIOS and after a reboot it all starts again I would expect: 1. Chronyd is called before other services that aren't needed by chronyd itself. 2. The new time should be saved to BIOS when chronyd use ntp to sync the clock
Guys, the thing here is that there are two broken ways to handle RTC in local time: i.e. where userspace syncs the system clock to RTC on shutdown, and where it doesn't. Both ways are broken: The first choice breaks the DST change Windows will do on the next boot. The second choice will forget never do automatic DST changes on Linux and the clock is will continue to be wrong on each subsequent Linux boot. Given that local RTC is a hack to be nice to Windows I'm strongly of the opinion that we shouldn't muck with Windows' DST logic if it is enabled, and hence stay away from the RTC. If you want Windows compatibility you get Windows compatibility -- and nothing else. If you are willing to pass control over the RTC to Windows, then pass it the control to the RTC, don't come up with something half-baked, where you muck with it too in a away that just confuses Windows. On RTC in UTC we have very little reason to believe that the system clock was any more accurate than the RTC unless NTP is used. If NTP is used the kernel will write the system clock to the RTC every 11 minutes anyway, hence there's no point at all to sync system clock to RTC at all. And that's why we don't do that. So, closing again. I see nothing here that systemd could do any better.
Ok, a couple of questions again: you said "If NTP is used the kernel will write the system clock to the RTC every 11 minutes", but on my system this is clearly not happening. Should I fill a new bug against kernel? In this case is this a Fedora thing and I should open the bug in redhat bugzilla, or is a standard kernel feature and I should report to kernel? Another bug I'm seeing is that Sendmail crashes and it should be manually restarted if the clock is turned backwards 1 hour. Does it makes sense opening a new bug against sendmail? Or is systemd that should periodically check the status of critical system services and try to restart them if they're dead? Thank you.
(In reply to comment #20) > If NTP is used the kernel will write the system clock to the RTC every > 11 minutes anyway, hence there's no point at all to sync system clock > to RTC at all. Lennart, as comment #11 tried to explain, the kernel's periodic 11-minutes sync does not write the full time to the RTC, it merely corrects for errors within a window of modulo 30 minutes. So it only touches minutes and seconds in the RTC, it does not fix the hours. Doesn't that break your assumptions? Does anaconda even default to setting "RTC runs in UTC"? I don't remember.
Please see bug https://bugzilla.redhat.com/show_bug.cgi?id=753642 which does not involve daylight/standard time changes, but rather a simple install setting timezone to CST and then use. chronyd's adjusting the time drastically during boot catches some components seeing both the boot time value and then another new value some (6) hours difference apart. Wreaks havoc on DHCP lease timestamps, for instance.
It is now apparent that syncing the system clock to hw clock on system shutdown increases the system robustness regardless of whether the hw clock is UTC or not. Although it does not solve the problems in a "perfect" way remember please that perfect is the enemy of the good. Reopening.
Also, there seems to be a problem with the kernel RTC synchronization, see bug #753487.
I hit this one-hour-off problem on two different openSUSE-12.1 systems with systemd not setting RTC on shutdown anymore. None of the two systems actually runs Windows and at least one even had the RTC set to UTC mode. When you only rely on the kernel to update the RTC, it will remain wrong, whenever it was wrong by more than 15 or 30 minutes (e.g. skewed after long time off or without ntp) so hwclock needs to be written - and before shutdown is the best time for it, because ntp will have run for a long time and be well synchronized. The problem with Windows is that a) it does not use RTC as UTC and b) it changes the clock by 1 hour without actually knowing anything about the real time... but I feel that this should be fixed by MICROS~1 rather than all Linux users suffering from the workaround.
That sounds like a setting for ntp or crony. Systemd should stay out of the game fiddling with the RTC without knowing the current state of the time sync. It as no idea if NTP has successful run during bootup.
filed against openSUSE's NTP: https://bugzilla.novell.com/show_bug.cgi?id=737518
Given comment 27 I'm closing this as notabug. Please open new bug against ntp or chrony. Thanks
I tell Windows to use UTC on my dual boot machines, it's not that hard. Then the problem disappears. :) Gene
FYI, a new discussion about this problem is taking place in bug #816752.
I wonder how it is not a bug. DST changes are not saved, and AFAIK it is not done by chrony or ntp
This is certainly a bug. The component might be wrong, but it is a bug. My system RTC is set to local time. I do NOT synchronize my time with network. Two days ago the system time changed by one our because we are no longer in DST. that was fine. But unfortunately, the change was not saved to RTC. My system clock was correct, I shutdown my system. I turned it on afterwards, but the time was incorrect. Whoever has applied the DST settings must have changed RTC too. Would you please suggest the correct component instead of closing the bug?
Newer kernels do a full RTC sync these days in 11min mode, I figure this can be closed now.