[ntp:questions] Re: ntpd local synchronization fails?
wilhelm.greiner at web.de
Tue Nov 15 10:21:01 UTC 2005
* Danny Mayer <mayer at ntp.isc.org> schrieb:
> Wilhelm Greiner wrote:
> > i have an ntp multicast Client running, but it fails
> > to synchronize his local clock, ntp as Service is
> > running and delivering the right time. Only the
> > local clock will not be set.
> > NTP Version 4.1.2 is running on Linux 2.6.12.
> > I cant use ntpd Version 4.2.x, there is a multicast
> > Client bug.
> Not any more. Please upgrade to the latest ntp-dev snapshot. The fix
> should be in there.
Great! I try this.
The Problem is that there are any ntpd installations out now, i will
try to check if there is another possible config Option or so first.
It is not realy easy to roll out new binaries.
> > It seems that the step is to big and the kernel fails, is that true?
> If the step is too big and you didn't start ntpd with the -g flag, ntpd
> will exit.
Thats clear, my startscript adds -g, in my tests i set the time to
10 minutes in the future, i was looking that it alway be under 1000 s.
> > What can i do to force ntpd let the local clock synchronized?
> You don't synchronized to LOCAL, since that is by definition the same as
> the local clock.
OK, but it dont set the time, i stopped ntpd, set time 10 minutes to the
future and restart ntpd, _it doesnt_, also after a day, set the time.
When i look via date, the time stay in the future (600 sec round about).
In the syslog File i search for Entries like "time set -0.042078 s"
but i only found "time set 0.000000 s\nsynchronisation lost" in
the messages log.
After "nsynchronisation lost" nothing more appear.
> > [root at ntp log]# ntpq -p
> > remote refid st t when poll reach delay offset jitter
> > ==============================================================================
> > LOCAL(0) LOCAL(0) 6 l 50 64 377 0.000 0.000 0.015
> > *192.168.1.9 192.168.100.5 2 m 2 64 377 0.015 -21.714 16.686
> 192.168.1.* is not a valid multicast address. You can only use valid
> multicast addresses, though the system seems to be accepting it for
> reasons that I cannot easily tell. Use a valid multicast address. For
> IPv4 valid multicast addresses are in the range 18.104.22.168 to
22.214.171.124 or 126.96.36.199 should be valid...
> 188.8.131.52. That's what you need to use. Don't use Local unless you
> are serving other systems from this one, it is unlikely to do what you
> might think.
I have the local statement in the config for the reason that the multicast
link is broken for a while or so.
The ntpd acts as an Server and should keep serving when the multicast
Link is down or so.
The full config is:
# Multicast Addresse
# lokale Hardware Uhr als Fallback
fudge 127.127.1.0 stratum 6
# Pakete sind verzoegert unterwegs
# Authentifizierungs Schluessel
More information about the questions