1 |
Thanks Duncan. |
2 |
|
3 |
I am doing all the things you mentioned. But because you spent some |
4 |
time to help me I realized I should do a bit more work. I checked |
5 |
bugzilla and discovered this: |
6 |
|
7 |
http://bugs.gentoo.org/show_bug.cgi?id=105978 |
8 |
|
9 |
Commenting out /etc/conf.d/ntpd.conf -u ntp:ntp and now it works. |
10 |
|
11 |
Can't wait for that bug to get fixed. |
12 |
|
13 |
Now if I could just get a new kernel to boot. |
14 |
|
15 |
Thanks! |
16 |
|
17 |
Steve Herber herber@×××××.com work: 206-221-7262 |
18 |
Security Engineer, UW Medicine, IT Services home: 425-454-2399 |
19 |
|
20 |
On Tue, 14 Mar 2006, Duncan wrote: |
21 |
|
22 |
> Steve Herber posted <Pine.LNX.4.64.0603140110330.17364@×××××.com>, |
23 |
> excerpted below, on Tue, 14 Mar 2006 01:26:10 -0800: |
24 |
> |
25 |
>> I have a nice new A8N-SLI Premium system and I have two problems with it. |
26 |
>> The second problem I have is that ntpd fails with the error: |
27 |
>> |
28 |
>> Mar 13 08:41:54 fester ntpd[16778]: ntpd 4.2.0a@1.1191-r Thu Feb 23 |
29 |
>> 17:17:02 PST 2006 (1) |
30 |
>> Mar 13 08:41:54 fester ntpd[16778]: precision = 1.000 usec |
31 |
>> Mar 13 08:41:54 fester ntpd[16778]: Listening on interface wildcard, |
32 |
>> 0.0.0.0#123Mar 13 08:41:54 fester ntpd[16778]: Listening on interface lo, |
33 |
>> 127.0.0.1#123 |
34 |
>> Mar 13 08:41:54 fester ntpd[16778]: Listening on interface eth1, |
35 |
>> 192.168.168.6#123 |
36 |
>> Mar 13 08:41:54 fester ntpd[16778]: kernel time sync status 0040 |
37 |
> |
38 |
> A search of the ntp documentation (in /usr/doc/ntp-<ver>/html/*) for sync |
39 |
> status returns the error docs page. It refers to timex.h from the ntp |
40 |
> sources tarball. You probably have that tarball in your portage distdir. |
41 |
> A quick look here at the file... exerpted: |
42 |
> |
43 |
> /* |
44 |
> * Status codes (timex.status) |
45 |
> */ |
46 |
> [snip] |
47 |
> #define STA_INS 0x0010 /* insert leap (rw) */ |
48 |
> #define STA_DEL 0x0020 /* delete leap (rw) */ |
49 |
> #define STA_UNSYNC 0x0040 /* clock unsynchronized (rw) */ |
50 |
> #define STA_FREQHOLD 0x0080 /* hold frequency (rw) */ |
51 |
> |
52 |
> So... that would appear to simply say status unsynchronized. Not a |
53 |
> problem as that's the way it's supposed to start. In fact, I figured |
54 |
> that's what it meant, as mine always starts that way, but the status |
55 |
> changes, later. |
56 |
> |
57 |
> Thus, either ntpd isn't failing after all, but still running and will |
58 |
> eventually sync, or if it's failing, the log as posted doesn't reveal why. |
59 |
> |
60 |
> A couple suggestions. |
61 |
> |
62 |
> 1: Check your timezone info. If you have your clock set to local time |
63 |
> but the timezone is set to UTC, assuming you aren't /at/ UTC local time, |
64 |
> you'll be off by several hours and ntpd will normally refuse to touch the |
65 |
> clock untl you set it to something closer to what ntpd can grok. |
66 |
> |
67 |
> 2: It's always best to run ntp-client as well as ntpd. The init ordering |
68 |
> will order ntp-client before ntpd if they are both in the same initlevel, |
69 |
> which is what you want. ntp-client does a quick-check and approximate |
70 |
> sync, stepping the clock as necessary to get it /close/ to the right time. |
71 |
> It is, however, a one-shot deal. ntpd then takes over and makes fine |
72 |
> adjustments as necessary to sync the clock more closely, then tracks it to |
73 |
> ensure it stays synced. By running ntp-client first, you ensure the clock |
74 |
> is close enough to correct that ntpd shouldn't protest. It will still |
75 |
> start as status 0040, but will sync up, usually within 15 minutes or so. |
76 |
> |
77 |
> -- |
78 |
> Duncan - List replies preferred. No HTML msgs. |
79 |
> "Every nonfree program has a lord, a master -- |
80 |
> and if you use the program, he is your master." Richard Stallman in |
81 |
> http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
82 |
> |
83 |
> |
84 |
> -- |
85 |
> gentoo-amd64@g.o mailing list |
86 |
> |
87 |
-- |
88 |
gentoo-amd64@g.o mailing list |