[ntp:questions] Not being able to sync the embedded target (client) with the host (server)

William Unruh unruh at invalid.ca
Sun Mar 16 18:11:40 UTC 2014


On 2014-03-15, Laszlo Papp <lpapp at kde.org> wrote:
> On Sat, Mar 15, 2014 at 5:19 PM, William Unruh <unruh at invalid.ca> wrote:
>> On 2014-03-14, Laszlo Papp <lpapp at kde.org> wrote:
>>> Nvm, I solved it by using busybox's ntp for the time being.
>>>
>>> On Fri, Mar 14, 2014 at 6:18 PM, Charles Swiger <cswiger at mac.com> wrote:
>>>> Hi--
>>>>
>>>> On Mar 14, 2014, at 9:05 AM, Laszlo Papp <lpapp at kde.org> wrote:
>>>>> I was told that this would not be a bug, although I could not figure
>>>>> out yet why it is not working.
>>>>
>>>> Told by whom?
>>>
>>> People in #ntp and on bugzilla.
>>>
>>>>> As far as I know, this should work
>>>>> simply by putting the following two lines into the client
>>>>> configuration:
>>>>>
>>>>> driftfile /etc/ntp.drift
>>>>> server 192.168.A.B iburst
>>>>
>>>> OK, that should be adequate for a minimal client config.
>>>
>>> Yes.
>>>
>>>> (BTW, also note that there is very little point in obscuring RFC-1918 addresses.)
>>>
>>> As you note that it does not matter much either way. Although, it is
>>> less likely to write a typo for A.B than concrete numbers, admittedly.
>>>
>>>>> Yet, the time is not getting sync'd. This is the server configuration, fwiw:
>>>>>
>>>>> server 0.pool.ntp.org iburst
>>>>> server 1.pool.ntp.org iburst
>>>>> server 2.pool.ntp.org iburst
>>>>> server 3.pool.ntp.org iburst
>>>>>
>>>>> # restrict default kod nomodify notrap nopeer noquery
>>>>> # restrict -6 default kod nomodify notrap nopeer noquery
>>>>>
>>>>> restrict 192.168.0.0 mask 255.255.255.0 nomodify
>>>>>
>>>>> restrict 127.0.0.1
>>>>> restrict -6 ::1
>>>>>
>>>>> driftfile /var/lib/ntp/ntp.drift
>>>>> logfile /var/log/ntp.log
>>>>>
>>>>> I do not see any error in the syslog either. I have tried to use "ntpd
>>>>> -q" for a one-shot set without much luck. I am probably doing
>>>>> something fundamentally wrong, but I was not able to figure out yet.
>>>>
>>>> Try running 'ntpq -pcrv 192.168.A.B' from your client.
>>>
>>> Yeah, I was running that.
>>>
>>>> Pay particular attention to the line containing status flags; if the server isn't
>>>> showing sync_ntp, then clients aren't going to be willing to trust it for time.
>>>
>>> Yep, that was there. The interesting part is that it works for the
>>> first time after a while, and it gets broken when I try to set the
>>> "date" explicitly by the corresponding command. For some reason, ntp
>>> cannot sync afterwards. Reboot and/or restarting the daemons may help
>>> though.
>>
>> Why would you be setting date explicitly?
>
> To see if it syncs up.

ntpd really does not like things (like you) adjusting the time behind
its back. It was designed with assumption that the system has a clock
whose frequency slowly wanders. It was not designed for a system whose
clock jumps around randomly. If that is what you want, get something
else than ntpd. (chrony does a better job if you are on linux or bsd)

The way you test ntpd is by looking to see how it performs over an
extended period of time.



>
> Although I am happy that the busybox ntpd worked out of the box
> without any complex configuration, just by command line parameters! It
> is a really nice user experience, so good job done in there, at least
> for me.



More information about the questions mailing list