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