Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   CentOS (http://www.linux-archive.org/centos/)
-   -   hwclock problem (http://www.linux-archive.org/centos/451415-hwclock-problem.html)

Jobst Schmalenbach 11-11-2010 11:41 PM

hwclock problem
 
Hi.

I run peridocally (from cron) on all of my machines

30 * * * * root /sbin/hwclock --systohc

All of those machines in question take their time via NTP
from the same local server, and that server gets its time
from a ntp pool.

Now I had to reboot a couple of them two days ago and to my surprise
all had problems with the time upon booting.

Here are the important files:

[root@XXXXXX ~] #>l /etc/adjtime
0.001687 1289518202 0.000000
1289518202
LOCAL

[root@XXXXXXX ~] #>l /etc/sysconfig/clock
ZONE="Australia/Melbourne"
UTC=false
ARC=false

So from my understanding the hwclock should contain the local time.

[root@XXXXXX ~] #>date
Fri Nov 12 11:26:23 EST 2010
[root@XXXXXX ~] #>hwclock
Fri 12 Nov 2010 11:26:42 EST -0.167976 seconds
[root@XXXXXX ~] #>

However on boot I get the following:

Nov 10 19:08:37 XXXXXX syslogd 1.4.1: restart.
Nov 10 19:08:37 XXXXXX kernel: klogd 1.4.1, log source = /proc/kmsg started.
Nov 10 19:08:37 XXXXXX kernel: Linux version 2.6.18-164.11.1.el5 (mockbuild@builder10.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.
1.2-46)) #1 SMP Wed Jan 20 07:32:21 EST 2010
Nov 10 19:08:37 XXXXXX kernel: Command line: ro root=/dev/sda2 vga=791
Nov 10 19:08:37 XXXXXX kernel: BIOS-provided physical RAM map:
...
...
Nov 10 19:08:51 XXXXXX kernel: IPv6 over IPv4 tunneling driver
Nov 10 08:08:52 XXXXXX ntpdate[2464]: step time server 192.168.1.1 offset -39599.950905 sec
Nov 10 08:08:52 XXXXXX xinetd[2447]: xinetd Version 2.3.14 started with libwrap loadavg labeled-networking options compiled in.

and off course dovecot falls over too "Time just moved backwards by 39599 seconds."

Now, 39600s is 11 hours, which is (inc DST) *MY* offset from Greenwich.


So what am I doing wrong?
The idea of running hwclock is to make sure that exactly the problem with dovecot does NOT occur, and ntp does not have a coughing fit when the hardware clock is not close to the correct time upon booting.
The last time I booted some of those machine was more than 200 days ago, so the hwclock will be skewed if I do not update it.



Jobst



--
Keyboard not found - please clean up desktop!

| |0| | Jobst Schmalenbach, jobst@barrett.com.au, General Manager
| | |0| Barrett Consulting Group P/L & The Meditation Room P/L
|0|0|0| +61 3 9532 7677, POBox 277, Caulfield South, 3162, Australia
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Robert Moskowitz 11-12-2010 12:26 AM

hwclock problem
 
On 11/11/2010 06:41 PM, Jobst Schmalenbach wrote:
> Hi.
>
> I run peridocally (from cron) on all of my machines
>
> 30 * * * * root /sbin/hwclock --systohc
>
> All of those machines in question take their time via NTP
> from the same local server, and that server gets its time
> from a ntp pool.
>
> Now I had to reboot a couple of them two days ago and to my surprise
> all had problems with the time upon booting.
>
> Here are the important files:
>
> [root@XXXXXX ~] #>l /etc/adjtime
> 0.001687 1289518202 0.000000
> 1289518202
> LOCAL
>
> [root@XXXXXXX ~] #>l /etc/sysconfig/clock
> ZONE="Australia/Melbourne"
> UTC=false
> ARC=false
>
> So from my understanding the hwclock should contain the local time.
>
> [root@XXXXXX ~] #>date
> Fri Nov 12 11:26:23 EST 2010
> [root@XXXXXX ~] #>hwclock
> Fri 12 Nov 2010 11:26:42 EST -0.167976 seconds
> [root@XXXXXX ~] #>
>
> However on boot I get the following:
>
> Nov 10 19:08:37 XXXXXX syslogd 1.4.1: restart.
> Nov 10 19:08:37 XXXXXX kernel: klogd 1.4.1, log source = /proc/kmsg started.
> Nov 10 19:08:37 XXXXXX kernel: Linux version 2.6.18-164.11.1.el5 (mockbuild@builder10.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.
> 1.2-46)) #1 SMP Wed Jan 20 07:32:21 EST 2010
> Nov 10 19:08:37 XXXXXX kernel: Command line: ro root=/dev/sda2 vga=791
> Nov 10 19:08:37 XXXXXX kernel: BIOS-provided physical RAM map:
> ...
> ...
> Nov 10 19:08:51 XXXXXX kernel: IPv6 over IPv4 tunneling driver
> Nov 10 08:08:52 XXXXXX ntpdate[2464]: step time server 192.168.1.1 offset -39599.950905 sec
> Nov 10 08:08:52 XXXXXX xinetd[2447]: xinetd Version 2.3.14 started with libwrap loadavg labeled-networking options compiled in.
>
> and off course dovecot falls over too "Time just moved backwards by 39599 seconds."
>
> Now, 39600s is 11 hours, which is (inc DST) *MY* offset from Greenwich.
>
>
> So what am I doing wrong?
> The idea of running hwclock is to make sure that exactly the problem with dovecot does NOT occur, and ntp does not have a coughing fit when the hardware clock is not close to the correct time upon booting.
> The last time I booted some of those machine was more than 200 days ago, so the hwclock will be skewed if I do not update it.

Have you looked at altering your /etc/sysconfig/ntpd file to directly
update your hardware clock?


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Rob Kampen 11-12-2010 12:28 AM

hwclock problem
 
Jobst Schmalenbach wrote:

Hi.

I run peridocally (from cron) on all of my machines

30 * * * * root /sbin/hwclock --systohc

All of those machines in question take their time via NTP
from the same local server, and that server gets its time
from a ntp pool.

Now I had to reboot a couple of them two days ago and to my surprise
all had problems with the time upon booting.

Here are the important files:

[root@XXXXXX ~] #>l /etc/adjtime
0.001687 1289518202 0.000000

1289518202
LOCAL

[root@XXXXXXX ~] #>l /etc/sysconfig/clock
ZONE="Australia/Melbourne"

UTC=false
ARC=false

So from my understanding the hwclock should contain the local time.

[root@XXXXXX ~] #>date
Fri Nov 12 11:26:23 EST 2010
[root@XXXXXX ~] #>hwclock
Fri 12 Nov 2010 11:26:42 EST -0.167976 seconds
[root@XXXXXX ~] #>

However on boot I get the following:

Nov 10 19:08:37 XXXXXX syslogd 1.4.1: restart.
Nov 10 19:08:37 XXXXXX kernel: klogd 1.4.1, log source = /proc/kmsg started.
Nov 10 19:08:37 XXXXXX kernel: Linux version 2.6.18-164.11.1.el5 (mockbuild@builder10.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.
1.2-46)) #1 SMP Wed Jan 20 07:32:21 EST 2010
Nov 10 19:08:37 XXXXXX kernel: Command line: ro root=/dev/sda2 vga=791
Nov 10 19:08:37 XXXXXX kernel: BIOS-provided physical RAM map:
...
...
Nov 10 19:08:51 XXXXXX kernel: IPv6 over IPv4 tunneling driver
Nov 10 08:08:52 XXXXXX ntpdate[2464]: step time server 192.168.1.1 offset -39599.950905 sec
Nov 10 08:08:52 XXXXXX xinetd[2447]: xinetd Version 2.3.14 started with libwrap loadavg labeled-networking options compiled in.

and off course dovecot falls over too "Time just moved backwards by 39599 seconds."

Now, 39600s is 11 hours, which is (inc DST) *MY* offset from Greenwich.


So what am I doing wrong?
The idea of running hwclock is to make sure that exactly the problem with dovecot does NOT occur, and ntp does not have a coughing fit when the hardware clock is not close to the correct time upon booting.
The last time I booted some of those machine was more than 200 days ago, so the hwclock will be skewed if I do not update it.



Last time I checked the shut down of a machine writes the system time to
the H/W prior to reboot. Thus the problem you describe should not occur
if proper shutdown occurs. HTH

Jobst






_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

"Brunner, Brian T." 11-12-2010 01:31 PM

hwclock problem
 
> and off course dovecot falls over too "Time just moved
> backwards by 39599 seconds."
>
> Now, 39600s is 11 hours, which is (inc DST) *MY* offset from
> Greenwich.
>
>
> So what am I doing wrong?


I have this problem when dead batteries on the mobo prevent the hwclock
from preserving the time.
Reboots don't show this (shutdown -r) but yanking the AC to fiddle with
switches on the cards (which takes pulling them out) or swapping
known-good with suspect-under-test gives me a boot-up time somewhere
back in August of 2006.
************************************************** *****************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom
they are addressed. If you have received this email in error please
notify the system manager. This footnote also confirms that this
email message has been swept for the presence of computer viruses.
www.Hubbell.com - Hubbell Incorporated**

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Jobst Schmalenbach 11-15-2010 12:38 AM

hwclock problem
 
Ok I try that, but the thing is:

* motherboards not that old
* its exactly 11 hours (+/- a couple of seconds) each time

Jobst



On Fri, Nov 12, 2010 at 09:31:55AM -0500, Brunner, Brian T. (BBrunner@gai-tronics.com) wrote:
>
> > and off course dovecot falls over too "Time just moved
> > backwards by 39599 seconds."
> >
> > Now, 39600s is 11 hours, which is (inc DST) *MY* offset from
> > Greenwich.
> >
> >
> > So what am I doing wrong?
>
>
> I have this problem when dead batteries on the mobo prevent the hwclock
> from preserving the time.
> Reboots don't show this (shutdown -r) but yanking the AC to fiddle with
> switches on the cards (which takes pulling them out) or swapping
> known-good with suspect-under-test gives me a boot-up time somewhere
> back in August of 2006.
> ************************************************** *****************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom
> they are addressed. If you have received this email in error please
> notify the system manager. This footnote also confirms that this
> email message has been swept for the presence of computer viruses.
> www.Hubbell.com - Hubbell Incorporated**
>
> _______________________________________________
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos

--
If builders built buildings the way Microsoft wrote programs, then the first woodpecker that came along would destroy civilization.

| |0| | Jobst Schmalenbach, jobst@barrett.com.au, General Manager
| | |0| Barrett Consulting Group P/L & The Meditation Room P/L
|0|0|0| +61 3 9532 7677, POBox 277, Caulfield South, 3162, Australia
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Jorge Fábregas 11-15-2010 01:02 AM

hwclock problem
 
On Thursday 11 November 2010 20:41:45 Jobst Schmalenbach wrote:
> Now I had to reboot a couple of them two days ago and to my surprise
> all had problems with the time upon booting.

Hi,

Are you 100% sure that your timezone file (/etc/localtime) corresponds to the
one Australia/Melbourne? Try this:

diff /etc/localtime /usr/share/zoneinfo/Australia/Melbourne

Besides that, try to see if there's any script within /etc that tries to set
the TZ variable somewhere as it seems it is trying to set your system time to
flat UTC.

If I understand correctly, your hardware clock indeed is storing "localtime"
as seen on the output when you are booting... but as soon as ntpd kicks in, it
sets the system time to UTC (which is 11 hours behind your localtime). Right?

HTH,
Jorge
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Jorge Fábregas 11-15-2010 01:14 AM

hwclock problem
 
On Thursday 11 November 2010 20:41:45 Jobst Schmalenbach wrote:
> Nov 10 08:08:52 XXXXXX ntpdate[2464]: step time server 192.168.1.1 offset
> -39599.950905 sec

Also, try to disable ntpdate with "chkconfig ntpdate off" and reboot the machine
and see if that solves the problem. If it does, then you can concentrate on
ntpdate...

--
Jorge
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

John R Pierce 11-15-2010 02:03 AM

hwclock problem
 
On 11/14/10 5:38 PM, Jobst Schmalenbach wrote:
> Ok I try that, but the thing is:
>
> * motherboards not that old
> * its exactly 11 hours (+/- a couple of seconds) each time


sounds like a conflict between time zones. a PC hardware clock could
be set to UTC or local time. I always set my PC Hardware clocks to
localtime, and make sure Unix knows it. darnit, I can't remember where
that setting is right now.




_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

"Simon Billis" 11-15-2010 10:13 AM

hwclock problem
 
Hi,

> On 11/14/10 5:38 PM, Jobst Schmalenbach wrote:
> > Ok I try that, but the thing is:
> >
> > * motherboards not that old
> > * its exactly 11 hours (+/- a couple of seconds) each time
>
>
> sounds like a conflict between time zones. a PC hardware clock could
> be set to UTC or local time. I always set my PC Hardware clocks to
> localtime, and make sure Unix knows it. darnit, I can't remember
> where
> that setting is right now.

Seems to me that the kernel is expecting the hardware clock to be at UTC.
This may be a bug in hwclock or a typo in /etc/sysconfig/clock

Have you tried to setting the hwclock to UTC and leaving it there?

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Robert Nichols 11-15-2010 03:02 PM

hwclock problem
 
On 11/11/2010 06:41 PM, Jobst Schmalenbach wrote:
> Hi.
>
> I run peridocally (from cron) on all of my machines
>
> 30 * * * * root /sbin/hwclock --systohc
>
> All of those machines in question take their time via NTP
> from the same local server, and that server gets its time
> from a ntp pool.
>
> Now I had to reboot a couple of them two days ago and to my surprise
> all had problems with the time upon booting.
>
> Here are the important files:
>
> [root@XXXXXX ~] #>l /etc/adjtime
> 0.001687 1289518202 0.000000
> 1289518202
> LOCAL
>
> [root@XXXXXXX ~] #>l /etc/sysconfig/clock
> ZONE="Australia/Melbourne"
> UTC=false
> ARC=false
>
> So from my understanding the hwclock should contain the local time.
>
> [root@XXXXXX ~] #>date
> Fri Nov 12 11:26:23 EST 2010
> [root@XXXXXX ~] #>hwclock
> Fri 12 Nov 2010 11:26:42 EST -0.167976 seconds
> [root@XXXXXX ~] #>
>
> However on boot I get the following:
>
> Nov 10 19:08:37 XXXXXX syslogd 1.4.1: restart.
> Nov 10 19:08:37 XXXXXX kernel: klogd 1.4.1, log source = /proc/kmsg started.
> Nov 10 19:08:37 XXXXXX kernel: Linux version 2.6.18-164.11.1.el5 (mockbuild@builder10.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.
> 1.2-46)) #1 SMP Wed Jan 20 07:32:21 EST 2010
> Nov 10 19:08:37 XXXXXX kernel: Command line: ro root=/dev/sda2 vga=791
> Nov 10 19:08:37 XXXXXX kernel: BIOS-provided physical RAM map:
> ...
> ...
> Nov 10 19:08:51 XXXXXX kernel: IPv6 over IPv4 tunneling driver
> Nov 10 08:08:52 XXXXXX ntpdate[2464]: step time server 192.168.1.1 offset -39599.950905 sec
> Nov 10 08:08:52 XXXXXX xinetd[2447]: xinetd Version 2.3.14 started with libwrap loadavg labeled-networking options compiled in.
>
> and off course dovecot falls over too "Time just moved backwards by 39599 seconds."
>
> Now, 39600s is 11 hours, which is (inc DST) *MY* offset from Greenwich.
>
>
> So what am I doing wrong?
> The idea of running hwclock is to make sure that exactly the problem with dovecot does NOT occur, and ntp does not have a coughing fit when the hardware clock is not close to the correct time upon booting.
> The last time I booted some of those machine was more than 200 days ago, so the hwclock will be skewed if I do not update it.

By any chance is /etc/localtime a symlink to a file system that is not mounted
early in the boot process? That's why /etc/localtime is normally a _copy_ of
the appropriate zoneinfo file.

--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


All times are GMT. The time now is 01:34 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.