>>> Lars Marowsky-Bree <[email protected]> schrieb am 11.04.2013 um 13:18 in
Nachricht
<[email protected]>:
> On 2013-04-11T11:48:32, Ulrich Windl <[email protected]>
wrote:
> 
> > > Annoying but harmless underflow in pacemaker. Since fixed, and will be
> > > fixed before it can occur next time (winter time). Sorry.
> > While talking on it: Is it a known problem in SLES11 SP2 that hosts gain 
> one hour during boot even though NTP is properly configured? (I changed some

> setting in /etc/sysconfig/ntp in the meantime, hopefully fixing that)
> 
> No. The typical cause for this is the bios clock acting up, and/or not
> having the right UTC versus local time setting.

Let me comment: When the clock is synchronized with NTP, the hardware clock
should be updated from the system clock. I think I had presented a solution for
this about 10 years ago (the kernel will update the hardware clock when NTP
adjusts the clock, or when the system time was changed through syscall). Many
people had said that solution is not good enough, and they could do better. As
it seems those people forgot to let any code follow their words ;-)

"8.3.4.1.1. What does set_rtc_mmss: can't update from 54 to 5 mean?

The function set_rtc_mmss() updates minutes and seconds of the CMOS clock from
system time. It does not update the hour or date to avoid problems with
timezones.[1] The message shown was added to make users and implementers aware
of the problem that not all time updates will succeed.

Imagine the system time is 17:56:23 while the CMOS clock is already at
18:03:45. Updating just minutes and seconds would set the hardware clock to
18:56:23, a wrong value. The solution for this problem is either to wait a few
minutes, or to install a kernel patch that fixes the problem. Normally a wrong
time in the hardware clock will not show up until after reboot, or maybe after
APM slowed down your system."


Note: I think this code is no longer present in the kernel.

"8.3.4.4.2. With PPSkit-0.9 my hardware clock is set to UTC; why?

See also Q: 8.3.1.1.2.. According to the README file that comes along with
PPSkit-0.9, there are some new features:


●The hardware clock's date and time is set whenever it is updated.
Previously only the minutes and seconds were updated. Naturally this requires
different treatment depending on whether the hardware clock is expected to run
in UTC or local time.

●The hardware clock is updated whenever the system time is set (actually it
happens 0.5s after the next second begins, but that's only because of the
strange hardware).

●The interval for automatic updates of the RTC can be modified. Automatic
updates can be disabled completely.

These changes were designed to make everybody happy. Therefore some new
sysctl() functions were introduced. These variables can be accessed through
files in /proc/sys/kernel/time:


rtc_runs_localtime
Decides whether RTC is set to UTC or local time. A value of 0 means UTC.

rtc_update
Determines the interval after which the RTC is updated. If the value is 0, no
automatic update happens.

timezone
Determines the kernel timezone. This is a pair of values: The first value
determines the minutes west of GMT, and the second value determines whether DST
is in effect. These values are used when the kernel has to convert UTC to local
time.

As up to these changes most people did not care much about the kernel's
timezone, the time zone is not set correctly in many cases. There is a trick to
copy the current timezone to the kernel.[2] I use the following code in
/sbin/init.d/boot.local (SuSE Linux):

timezone=$(date +%z | sed -e
's/\([0-9][0-9]\)\([0-9][0-9]\)/(60*10#\1+10#\2)/')
TIMESYSCTL=/proc/sys/kernel/time
[ -w $TIMESYSCTL/timezone ] && echo $((-$timezone)) 0 >$TIMESYSCTL/timezone
[ -w $TIMESYSCTL/rtc_runs_localtime ] && echo 1
>$TIMESYSCTL/rtc_runs_localtime

For Slackware Linux the proper place seems to be rc.local. (Contributed by
Richard M. Hambly)"

Regards,
Ulrich


 
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

Reply via email to