Daylight savings changeover - RTC not being re-written.

English Install/Boot/Login
1

My system was powered down at daylight savings changeover. Like many Linux users, I keep my RTC on local time so that I can still boot XP on the odd occasion.

With my older Linux distros, ntpd would correct the system time during the next boot, and the altered system time would be copied to the RTC on shutdown (by hwclock).

This no longer seems to happen. During boot, ntpd corrects the system-time, and the users sees the right time, but the corrected time is never copied to the RTC. The issue only becomes a problem if the system is booted without access to any ntp servers - in which case the system time is visible uncorrected.

I was under the impression that the kernel’s 11-minute save-RTC mode should preserved any NTP corrected system-time to the RTC. And failing that, a shutdown triggered hwclock --systohc should have also corrected the RTC. How come neither work for openSUSE (11.2)?

Another issue is that having initially booted without an internet connection, ntpd refuses to re-resolve the the ntp servers and has to be manually restarted. Shouldn’t ntpd have a roadwarrior option to retry resolving hosts? - this would save having to manually kick it via the command line or cron.

2

On 2010-07-07 22:36 GMT mchnz wrote:

>
> My system was powered down at daylight savings changeover. Like many
> Linux users, I keep my RTC on local time so that I can still boot XP
> on the odd occasion.

I understand that by RTC you mean the “cmos clock”.

> With my older Linux distros, ntpd would correct the system time during
> the next boot, and the altered system time would be copied to the RTC
> on shutdown (by hwclock).

The correction should happen without recourse to ntp. Actually, if time
is to bad at that moment, weird things can happen. As you are seeing.

And notice that Windows has its own ideas and will (may) adjust to the
daylight change - again.

> This no longer seems to happen. During boot, ntpd corrects the
> system-time, and the users sees the right time, but the corrected time
> is never copied to the RTC. The issue only becomes a problem if the
> system is booted without access to any ntp servers - in which case the
> system time is visible uncorrected.

The cmos clock is only updated when the system is halted correctly -
but as there was a time-jump, that time jump will distort the
calculations when you boot again.

> I was under the impression that the kernel’s 11-minute save-RTC mode
> should preserved any NTP corrected system-time to the RTC. And
> failing that, a shutdown triggered hwclock --systohc should have also
> corrected the RTC. How come neither work for openSUSE (11.2)?

No, that cyclic update is not done in oS, never has, AFAIK.

And the shutdown technique doesn’t work because there was a time jump.

Ok, the sequence to correctly setup the hour is:

  • correct the clock by using ntp or the command “date something” as
    root.

  • update the cmos clock (hwclock --systohc)

  • remove the file keeping track of cmos adjustements,
    ie, /etc/adjtime, then update the cmos again:

cat /etc/adjtime (watch to see if it says UTC or local)
rm /etc/adjtime
hwclock --systohc --utc|–localtime

Verify both clocks:

date
hwclock

That should be it.

> Another issue is that having initially booted without an internet
> connection, ntpd refuses to re-resolve the the ntp servers and has to
> be manually restarted. Shouldn’t ntpd have a roadwarrior option to
> retry resolving hosts? - this would save having to manually kick it
> via the command line or cron.

It might do, but very slowly. I’m unsure of that.

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” GM (Elessar))

3

Thanks for taking the time to suggest a solution. As it happens, I’d already corrected the problem by following a procedure similar to the one you’ve proposed and was really looking for explanations - some of which you also covered - Thanks. Some comments on your post:

Although it would be nice if ntp were not involved, the only way that could have happened would be if I left the machine on during the cut over. If it had been on, local time would have auto-updated and on shutdown it would have been saved to CMOS. In my case because the machine was off, at next boot Linux just carried on with my old uncorrected time, but then ntpd started up and jumped the time to the correct value. Unbeknownst to me, this was happening at every subsequent boot until I boot without an Internet connection - so things were kind-of OK.

As you mentioned, I suspect (but have not confirmed) that the ntpd corrected time was not being written back to the cmos clock because the time had suffered a large jump and was considered now too different for safe write-back.

As to the cyclic update never being done by the kernel: that was true until recent times, but if you read through the following howto, you will see this has changed:

[The Clock Mini-HOWTO: How Linux Keeps Track of Time](http://tldp.org/HOWTO/Clock-2.html)

I looked at the openSUSE /etc/rc.d/boot.clock and it is testing ELEVENMIN_MODE and doing something different if it is on. As hinted at in the howto, not everyone sees ELEVENMIN_MODE as a good idea. I did wonder if this is part of the problem, and looked at the kernel source - the code for ELEVENMIN_MODE seems to do some testing of fitness before updating the CMOS - but I haven’t looked into it in detail - I’ve burnt through too much time already. I thought I’d see if anyone here was already clued up and would save me the trouble of investigating further or perhaps prompt someone to look at how to solve this in openSUSE for all users.

And, yes XP has it own ideas - but I think it normally asks - or at least I had it setup that way (it’s so seldom that I boot to XT, that I’m no longer sure what I’ve done on that side of things).

Thanks again for the prompt response.

4

The problem is that you use local time as a base to bow to MS requirements. I do not believe you would have had the problem if you had used UTC , since that does not require a change to the RTC. UTC as a base is a far more rational way to maintain a time system.

5

Rational, but perhaps not practical - certainly not for mass-market reception of Linux in an MS dominated market. However, I have read that some MS operating systems support using UTC, so you are right, I will google a little and see if I can run XP in UTC.

Note, even having converted to UTC, it’s still not nice that when temporarily off the net, ntpd packs a sad until restarted - not every Linux machine is an always connected server.

6

There is no way the program can know that the RTC was changed or not after all it may have been changed by Windows then it would still be off if it changed it again… It really is a no win situation and we all must live with Windows stupidity.

7

mchnz wrote:

>
> My system was powered down at daylight savings changeover. Like many
> Linux users, I keep my RTC on local time so that I can still boot XP
> on the odd occasion.

I learn new things every day - XP won’t boot unless the clock is set to
local time?!?!

(I keep all my system clocks running UTC).

–
Per Jessen, Zürich (19.3°C)
http://en.opensuse.org/User:Pjessen

8

mchnz wrote:

>
> Rational, but perhaps not practical - certainly not for mass-market
> reception of Linux in an MS dominated market.

Sure it is - the regular convert won’t even see it, so why should it
cause a problem?

> Note, even having converted to UTC, it’s still not nice that when
> temporarily off the net, ntpd packs a sad until restarted - not every
> Linux machine is an always connected server.

Uh, if a time-source is unavailable, ntp will typically go into stratus
10 mode and try to sync as best it can (by knowing the drift of the
local clock for instance).

–
Per Jessen, Zürich (19.4°C)
http://en.opensuse.org/User:Pjessen

9

You misunderstand - XP will boot, but the time will be wrong, having files with incorrect dates and times is a major hassle.

10

Why not run XP in VBox? Saves you having to reboot the machine too.

11

And in the current configuration it will never right itself without manual intervention. For road warriors that come and go from the net, ntpd is not the best, chrony is a better choice ( Chrony ). See the chrony FAQ for the issues with ntpd under these circumstances. I last used chrony back in the nineties, it helped me keep 400 Linux road-warriors in clock sync. Your post prompted me to revisit it - thanks for nudging my memory.

As I said earlier, I really knew how to fix the issue, but I wanted to prompt some thinking on the wider issues. Ntpd does not cover all cases well, and the artificial division of responsibility for managing the system and cmos clocks isn’t that pretty either.

I’m not trying to dismiss Linux or ntpd, I’ve been using Linux since 0.11, so I’m here for the long haul. Of the mature KDE supporting distros, openSUSE is the best I’ve tried, but there’s always room to improve.

12

Good suggestion. I did tend to use XP for flight sims, so performance was an issue. But these days I hardly use it at all on this desktop, so maybe the time has come.

But I also can’t be bothered nursing a MS install just at the moment, so I will likely convert XP to use UTP via the RealTimeIsUniversal registry setting and shelve the problem for a while. Plus I may switch to chrony to get round any ntpd issues when booting disconnected from the net.

13

mchnz wrote:

> And in the current configuration it will never right itself without
> manual intervention.

I don’t quite get that - we run a stratus 0 time-source based on DCF77;
every now and then a time packet isn’t decoded properly, and ntpd
switches to stratum 1 (an external source) or stratum 10 (localhost).
When the next packet is decoded, it goes back to stratum 0.

> For road warriors that come and go from the net, ntpd is not the best,

Of course not - they hardly need a clock with sub-second accuracy. ntpd
is primarily for servers.

> As I said earlier, I really knew how to fix the issue, but I wanted to
> prompt some thinking on the wider issues. Ntpd does not cover all
> cases well,

ntp does very well when it is used as intended.

–
Per Jessen, Zürich (22.6°C)
http://en.opensuse.org/User:Pjessen

14

I said: Ntpd does not cover all cases well.
You said: ntp does very well when it is used as intended.

I asume you mean Ntpd. I have no problem with ntp - Chrony still uses ntp. As described by its documentation, chrony covers cases that ntpd was not intended for. So we’re pretty much saying the same thing.

Road-warriors can be servers too - perhaps substitute net-intermittently connected machines, not necessarily laptops.

15

mchnz wrote:

>
> I said: Ntpd does not cover all cases well.
> You said: ntp does very well when it is used as -intended-.
>
> I asume you mean Ntpd. I have no problem with ntp

Sorry, I left out a ‘d’ - but ntpd is the NTP reference implementation,
to me they’re one and the same.

> - Chrony still uses ntp. As described by its documentation, chrony
> covers cases that ntpd was not intended for. So we’re pretty much
> saying the same thing.

I don’t know chrony - for temporarily setting time, I have most often
used ntpdate at boot-up. It’s been deprecated by ntpq I think.

> Road-warriors can be servers too - perhaps substitute
> net-intermittently connected machines, not necessarily laptops.

I guess it varies - my servers are in very stationary 19" racks behind a
couple of strong doors :slight_smile:

–
Per Jessen, Zürich (25.1°C)
http://en.opensuse.org/User:Pjessen