ntpd just sits there and does nothing
[LoN]Kamikaze
LoN_Kamikaze at gmx.de
Fri Jul 20 09:34:29 UTC 2007
Stefan Lambrev wrote:
> Hi,
>
> [LoN]Kamikaze wrote:
>> Doug Hardie wrote:
>>
>>> On Jul 19, 2007, at 10:08, [LoN]Kamikaze wrote:
>>>
>>>
>>>> As the subject says, on my 6-stable systems ntpd just sits there and
>>>> does
>>>> nothing. The logs only mention when the daemon gets started or shut
>>>> down. It
>>>> complains when servers are not reachable, but does nothing when they
>>>> are available.
>>>>
>>>> The drift file always contains 0.00.
>>>>
>>>> ntpdate and openntpd both successfully manage to set the time, so I
>>>> suppose
>>>> it's a problem with ntpd.
>>>>
>>> Are you on a static IP address? If not, ntpd obtains its IP address
>>> when it starts up and uses it forever. If your IP address changes then
>>> it will not be able to communicate with the upstream ntp servers. It
>>> has to be restarted everytime your IP address changes.
>>>
>>
>> I have a static address. The trouble is it seems to operate fine, only it
>> forgets to change the time when it differs from the time servers too
>> much.
>> Sometimes my clock goes wrong more than 1 second within a day.
>>
> ntpd will not change time if the difference is too big - I think it
> should be less then 1000s.
> ntpdate will :)
>
> Also if you have increased your kernel secure level 2+ :
>
> In addition, kernel time changes are restricted to less than or
> equal to one second. Attempts to change the time by more than
> this
> will log the message ``Time adjustment clamped to +1 second''.
>
> So grep for ntpd in /var/log/messages and I'm sure you will find the
> problem.
>
> Other problem that I see is if you are behind NAT/firewall.
> Because ntpd make a request and wait for response on different port, so
> check your firewall configuration and blocked packets.
My securelevel is -1, even starting with an accurate clock ntpd just slowly
lets it drift away. I'm behind a 2 NATs, one of which I have no access to.
However openntpd and ntpdate don't seem to be troubled by this.
More information about the freebsd-stable
mailing list