[ntp:questions] no servers, synchronized, time reset
twoerner at gmail.com
Tue Feb 26 18:40:03 UTC 2013
Thanks for taking a look.
On Tue, Feb 26, 2013 at 12:25 PM, unruh <unruh at invalid.ca> wrote:
>> When NTPd is started up on the client, it will initially set its time with:
>> # ntpd -n -q -g
> ntpd will step the clock if it decides that the time is out by .128 sec.
> It will die if the time is out by something like 1000 sec which is why
> the -g is there, so that on startup the system can reset the clock by a
> large amount without dying. But that is one time step. If it ever goes
> out by that amount again ntpd will die.
This particular invocation of ntpd is a one-time call; it is run only
once when ntp is starting up. But after this is complete, NTP is then
run with only the "-g" option.
> Why are you running such an ancient version of ntpd?
Hopefully you can appreciate that if it were up to me, all the
software on this device would be much newer. :-) But as this is a
shipping device, the "higher ups" see too much risk in changing
arbitrary components without lots of justification. Fortunately I was
able to build a newer version against this older product, so there is
hope this component can be upgraded if required.
> That is completely nuts and indicates something is seriously seriously
> seriously wrong. It should never reset the time, except on startup. Ever
> resetting the time indicates serious problems.
> Perhaps some program is fighting with ntpd and resetting the clock
> itself for some reason.
Okay, thanks. This actually makes me feel better. It seemed crazy to
me, I'm glad for the confirmation.
Any ideas on what could potentially be fighting with NTP? It's a
pretty minimalist Linux system and I'm fully in control of everything
that runs on the device. Could the Linux kernel be interfering?
> Look in the measurements log file to see what the offsets are that your
> system is getting, and to see what the roundtrip delays are.
Okay, I'll keep an eye on those.
> Upgrade your ntpd. Try again.
I have updated to 4.2.7p357 (on the client) and am currently seeing:
ind assid status conf reach auth condition last_event cnt
1 28829 963a yes yes none sys.peer sys_peer 3
ntpq> rv 28829
associd=28829 status=963a conf, reach, sel_sys.peer, 3 events, sys_peer,
srcadr=184.108.40.206, srcport=123, dstadr=220.127.116.11, dstport=123,
leap=00, stratum=4, precision=-18, rootdelay=171.021, rootdisp=143.967,
reftime=d4d77deb.0014b599 Tue, Feb 26 2013 13:31:07.000,
rec=d4d77e22.3a422ffa Tue, Feb 26 2013 13:32:02.227, reach=377,
unreach=0, hmode=3, pmode=4, hpoll=4, ppoll=5, headway=7, flash=00 ok,
keyid=0, offset=1.186, delay=0.355, dispersion=1.253, jitter=2.061,
filtdelay= 0.35 8.63 4.92 4.32 3.83 0.88 1.41 4.32,
filtoffset= 1.19 5.28 2.55 -0.80 -0.44 1.34 0.67 -0.87,
filtdisp= 0.01 0.50 1.00 1.48 1.97 2.47 2.96 3.44
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version="ntpd 4.2.7p357 at 1.2483-o Tue Feb 26 16:15:26 UTC 2013 (1)",
processor="i686", system="Linux/18.104.22.168-rt15", leap=00, stratum=5,
precision=-19, rootdelay=171.201, rootdisp=234.419,
reftime=d4d77e82.39f3d6e1 Tue, Feb 26 2013 13:33:38.226,
clock=d4d77efe.7c5a3986 Tue, Feb 26 2013 13:35:42.485, peer=28829, tc=4,
mintc=3, offset=1.051154, frequency=25.650, sys_jitter=0.000000,
The system has been up now for 3.5 hours with no resets reported in
the log file:
$ tail -f ntp.log
26 Feb 11:38:04 ntpd: ntpd 4.2.7p357 at 1.2483-o Tue Feb 26
16:15:26 UTC 2013 (1): Starting
26 Feb 11:38:04 ntpd: Command line: ntpd -g --logfile=/var/log/ntp.log
26 Feb 11:38:04 ntpd: proto: precision = 1.392 usec (-19)
26 Feb 11:38:04 ntpd: Listen and drop on 0 v4wildcard 0.0.0.0:123
26 Feb 11:38:04 ntpd: Listen normally on 1 eth0 192.168.0.50:123
26 Feb 11:38:04 ntpd: Listen normally on 2 eth0:0 10.0.0.50:123
26 Feb 11:38:04 ntpd: Listen normally on 3 lo 127.0.0.1:123
26 Feb 11:38:04 ntpd: Listen normally on 4 eth1 22.214.171.124:123
26 Feb 11:38:04 ntpd: peers refreshed
More information about the questions