23

I have a machine that experienced some troubles with some of the real time stuff that I'm running. One lead that I have is that NTP daemon may have moved the time, causing false timeouts.

How do I find out if NTP daemon did indeed move time at all? Any logs? I do see NTP daemon restart in /var/log/messages, but I don't know if time adjustment should be there as well.

to clarify: I need to understand it from the logs, after the event. May be 2 days after the time was adjusted. Running commands to see the current status doesn't help.

n-alexander
  • 453

5 Answers5

9

You can use ntpdc -c sysinfo command for querying ntpd status. It returns an output similar to this:

system peer:          0.0.0.0
system peer mode:     unspec
leap indicator:       11
stratum:              16
precision:            -20
root distance:        0.00000 s
root dispersion:      338.44917 s
reference ID:         [73.78.73.84]
reference time:       00000000.00000000  Thu, Feb  7 2036  8:28:16.000
system flags:         auth monitor ntp kernel stats
jitter:               0.000000 s
stability:            0.000 ppm
broadcastdelay:       0.003998 s
authdelay:            0.000000 s
Janne Pikkarainen
  • 8,015
5

The driftfile (/var/lib/ntp/drift) does not measure the difference between the local time and the time calculated by ntpd based on time servers contacted.

Instead it is the estimated drift (frequency error) of the local clock (in ppm). This value is updated by ntpd once an hour and does not decrease over time.

As far as I can tell the value is used by ntpd after a reboot to estimate how wrong the local clock is (the local clock runs even when the machine is powered off).

Example: Content of the file: 5 Machine was powered down 1 day (86400 s) 5 ppm of 86400 is 0.432 => The local clock is 0.432 s "in the future"

The points are: - ntpd can now apply a first approximate correction to the local time (-0.432 s) immediately after starting - ntpd knows immediately, how wrong the local clock is (in this example: 5 ppm)

(I am not allowed to comment on the comment of Sirex so I added a new comment)

Martin Schneeweis
  • 59
4

ntpq -nc peers will show you your syncronization status with all peers.

BillThor
  • 11,345
  • 2
  • 28
  • 25
2

Sorry this is an old thread - hope I haven't broken a rule here :)

In /etc/ntp.conf, I have a line which looks like this:

#statsdir /var/log/ntpstats/

The description says to uncomment this line to log statistics. I've only just set up ntp on our server, so I'm not sure what it logs, but I ended up here looking for the same information, so hopefully this will help someone else.

dsl101
  • 121
1

Despite the recommendation of reading the NTP FAQ (even when possibly not updated recently), I'd like to update https://superuser.com/a/181348/964771:

As current versions disabled the private ntpdc protocol (because of possibly amplification attacks), you should use ntpq instead. ntpq has been enhanced and knows the sysinfo command, too:

# ntpq -nc sysinfo
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
system peer:        [2003:ee:2f02:8800:cece:1eff:fec8:f98f]:123
system peer mode:   client
leap indicator:     00
stratum:            4
log2 precision:     -25
root delay:         18.625
root dispersion:    47.180
reference ID:       195.81.109.67
reference time:     e8d6d32d.73b8521b  Sun, Oct 15 2023 23:07:57.452
system jitter:      0.000000
clock jitter:       29.838
clock wander:       5.124
broadcast delay:    -50.000
symm. auth. delay:  0.000

Another useful command is "read list" (rl):

# ntpq -nc rl
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version="ntpd 4.2.8p17@1.4004-o Wed Jun  7 12:00:00 UTC 2023 (1)",
processor="x86_64", system="Linux/5.14.21-150500.55.28-default", leap=00,
stratum=4, precision=-25, rootdelay=18.625, rootdisp=49.100,
refid=195.81.109.67,
reftime=e8d6d32d.73b8521b  Sun, Oct 15 2023 23:07:57.452,
clock=e8d6d435.8a3ce64f  Sun, Oct 15 2023 23:12:21.539, peer=4544, tc=7,
mintc=3, offset=-16.434911, frequency=-1.411, sys_jitter=0.000000,
clk_jitter=29.838, clk_wander=5.124

Probably the most important bits are the string clock_sync (sync_ntp) and the offset. rootdisp (root dispersion) give a general quality indicator: The lower the value the better the quality (in simple words).

Finally, RFC 8633 (Network Time Protocol Best Current Practices) may be a useful resource, too.

Last, but not least, UNIX systems that support the NTP time interface (as Linux does) can display the sync status of the kernel clock using ntptime:

# ntptime 
ntp_gettime() returns code 0 (OK)
  time e8d6d6eb.21a58710  Sun, Oct 15 2023 23:23:55.131, (.131432979),
  maximum error 533452 us, estimated error 29838 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset -386.699 us, frequency -1.411 ppm, interval 1 s,
  maximum error 533452 us, estimated error 29838 us,
  status 0x2001 (PLL,NANO),
  time constant 6, precision 0.001 us, tolerance 500 ppm,

Here the return value (OK) and the status (despite from estimated error) is important: if the return value or status indicate "TIME_ERROR" or "0x41", there is a problem to analyze.

U. Windl
  • 943