Gentoo Archives: gentoo-amd64

From: Thanasis <thanasis@××××××××××.org>
To: gentoo-amd64@l.g.o
Subject: Re: [gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown
Date: Sun, 14 Sep 2008 22:59:32
In Reply to: [gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown by Duncan <>
1 on 09/14/2008 11:44 AM Duncan wrote the following:
2 > Thanasis <thanasis@××××××××××.org> posted 48CA0929.60003@××××××××××.org,
3 > excerpted below, on Fri, 12 Sep 2008 09:16:09 +0300:
4 >
5 >
6 >> I have a laptop (Gateway T-1625), set up with ntpd to sync the system
7 >> time (with the "-s" option in /etc/conf.d/ntpd) to a local system of the
8 >> LAN.
9 >> What happens is tha although it syncs the system time successfully, it
10 >> often fails to sync the hardware clock during shutdown although I have
11 >> set CLOCK_SYSTOHC="yes" in /etc/conf.d/clock, and so I see those "One of
12 >> the files in /etc/{conf.d,init.d} or /etc/rc.conf has a modification
13 >> time in the future!" boot messages. Then I can confirm the difference in
14 >> time using the commands "date" and "hwclock --show" which shows the
15 >> difference, eg:
16 >>
17 >> # hwclock --show && date
18 >> Thu 11 Sep 2008 09:55:22 PM EEST -0.228853 seconds
19 >> Fri Sep 12 08:58:30 EEST 2008
20 >>
21 >
22 > EEST = Eastern European Summer Time, UTC+300, correct? (Just wikipediad
23 > it)
24 >
25 > Given the 11 hour time difference reported above, this may not be your
26 > problem, but here, I'm MST, (US Mountain Standard Time, UTC-700), and at
27 > one point I was having problems with a 14 hour difference because the
28 > system (clock init script? something anyway) was adjusting the wrong
29 > direction, UTC+700 instead of UTC-700. Obviously, that created
30 > problems...
31 >
32 > So... check your time zone settings.
33 >
34 > You may also want to step thru the init script logically and figure out
35 > what command it's actually using (or add a set -x right before the
36 > hwclock call, and a set +x right after, so you get the line from bash,
37 > running the initscript manually to see what it spits out), then issue the
38 > same exact command on the command line, where you can see the error
39 > output if any. I remember doing this while troubleshooting my problem
40 > (which eventually got fixed) here.
41 >
42 > FWIW I run ntp also, and have clock set to sync at shutdown. I've not
43 > had any problems since whatever it was that time got fixed. I'm still
44 > not sure exactly what was screwed up, but being 14 hours off until I got
45 > networking and started ntp wasn't fun, I'll tell you that!
46 >
47 > I also have the local clock set to local (UTC-700) time. That's not
48 > recommended for those who have time changes twice a year (except for
49 > those dual booting MS whatever, since it only does local time, IIRC), but
50 > AZ is one of the states here in the US that doesn't, so I don't have to
51 > worry about it.
52 >
53 > So that's something else to consider. You may have better luck toggling
54 > the system and hwclock to the other of UTC or local. I was about to give
55 > up and switch to UTC here, just to see if it would work, when either
56 > something I did or a package update fixed it and it just started
57 > working... <shrug>
58 >
59 > Finally, since you run ntp, it's not really vital that you have the
60 > hwclock synced /exactly/ anyway. Try setting your hardware clock from
61 > the BIOS... if it's off a few seconds, no biggee, the ntp sync with fix
62 > it. You can then turn the shutdown sync off, if desired, and just let
63 > the hardware clock run on its own, updating it manually if it gets too
64 > far off. By combining that with toggling UTC/local, and/or purposefully
65 > setting the hardware clock a few minutes ahead, you should be able to
66 > avoid the future filetime warnings, since the difference would be putting
67 > the filetimes in the past instead of the future. Just don't get too
68 > carried away, because rc uses those filetimes to track whether it needs
69 > to recache its service dependencies, etc, and if you have the hwclock set
70 > too far ahead, it won't detect config changes you've made and end up
71 > using stale data.
72 >
73 >
74 Duncan,
75 Thanks to your guidance, I found out that I had a large "systematic
76 drift rate" in /etc/adjtime file. This must have been the reason why the
77 hwclock was set behind. So I've set the drift to zero (actually just
78 deleted the file and let the system create a new one) and I hope things
79 will be ok now. :-)


Subject Author
[gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown Duncan <1i5t5.duncan@×××.net>