"Steven W. Orr" wrote:
> I need some help trying to figure out why ntp is dying in me. Here's the
> symptom:
>
> Oct 25 15:51:36 syslang ntpd: ntpd startup succeeded
> Oct 25 15:51:36 syslang ntpd[11148]: ntpd 4.0.99j Wed Aug 23 13:11:23 EDT
> 2000 (1)
> Oct 25 15:51:37 syslang ntpd[11148]: precision = 17 usec
> Oct 25 15:51:37 syslang ntpd[11148]: using kernel phase-lock loop 0041
> Oct 25 15:51:37 syslang ntpd[11148]: frequency initialized 46.433 from
> /etc/ntp/drift
> Oct 25 15:51:37 syslang ntpd[11148]: using kernel phase-lock loop 0041
> Oct 25 15:51:37 syslang ntpd[11148]: bind() fd 12, family 2, port 123,
> addr 224.0.1.1, in_classd=1 flags=0 fails: Address already in use
> Oct 25 15:51:37 syslang ntpd[11148]: ...multicast address 224.0.1.1 using
> wildcard socket
> Oct 25 15:56:25 syslang ntpd[11148]: time reset 1.228605 s
> Oct 25 15:56:25 syslang ntpd[11148]: kernel pll status change 41
> Oct 25 15:56:25 syslang ntpd[11148]: synchronisation lost
>
> and here's my ntp.conf:
>
> [root@syslang log]# cat /etc/ntp.conf
> #
> # Undisciplined Local Clock. This is a fake driver intended for backup
> # and when no outside source of synchronized time is available. The
> # default stratum is usually 3, but in this case we elect to use stratum
> # 0. Since the server line does not have the prefer keyword, this driver
> # is never used for synchronization, unless no other other
> # synchronization source is available. In case the local host is
> # controlled by some external source, such as an external oscillator or
> # another protocol, the prefer keyword would cause the local host to
> # disregard all other synchronization sources, unless the kernel
> # modifications are in use and declare an unsynchronized condition.
> #
> #server 127.127.1.0 # local clock
> #server dominator.eecs.harvard.edu # 140.247.60.28
> dominator.eecs.harvard.edu
> #server ntp0.cornell.edu # 192.35.82.50 # ntp0.cornell.edu
> server ticktock.wang.com # 150.124.136.4 #
> ticktock.wang.com
> server timex.cs.columbia.edu # 128.59.16.20 #
> timex.cs.columbia.edu
> server tock.cs.unlv.edu # 131.216.18.4 # tock.cs.unlv.edu
> server timeserver.cs.umb.edu # 158.121.104.4
> fudge 127.127.1.0 stratum 10
>
> #
> # Drift file. Put this in a directory which the daemon can write to.
> # No symbolic links allowed, either, since the daemon updates the file
> # by creating a temporary in the same directory and then rename()'ing
> # it to the file.
> #
> driftfile /etc/ntp/drift
> multicastclient # listen on default 224.0.1.1
> broadcastdelay 0.008
>
> #
> # Authentication delay. If you use, or plan to use someday, the
> # authentication facility you should make the programs in the auth_stuff
> # directory and figure out what this number should be on your machine.
> #
> authenticate no
>
> #
> # Keys file. If you want to diddle your server at run time, make a
> # keys file (mode 600 for sure) and define the key number to be
> # used for making requests.
> # PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote
> # systems might be able to reset your clock at will.
> #
> #keys /etc/ntp/keys
> #trustedkey 65535
> #requestkey 65535
> #controlkey 65535
>
> I really have no clue what's wrong. Can someone help? I just took the
> ntp.conf that came with Red Hat and added a coupld of servers that I
> thought were geographically close to me.
The default ntp.conf comes with the broadast/multicast client enabled. My
guess is that the servers and the multicast are trying to use the same port.
Comment out the following two lines and give it a shot.
multicastclient # listen on default 224.0.1.1
broadcastdelay 0.008
This does no good unless you have a server on your subnet that is issuing the
broadcast time packets anyway. IIRC for large networks with many clients this
can reduce network traffic but I have never used it. For broadcast, the delay
is hardcoded, as you can see, so you sacrifice some accuracy although not too
much for most applications I would guess.
If you still have trouble try
ntpdate timeserver
where timeserver is one of your timeservers. ntp won't adjust the time if it
is off too much.
HTH
Bret
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
