4

Looking for a script to (1) check status of ntp and (2) if it is within +/- 1 second of a given time server (eg 123.456.789.10). (3) In addition, system time should be checked to see if the timezone is set correctly (eg PST)

Here's what I have so far, checking the status of ntp:

#!/bin/bash

if [[ ! -x /usr/bin/ntpstat ]]
then
  echo "ntpstat is NOT installed: please install it"
  exit 3

res=$(/usr/bin/ntpstat)
rc=$?

case $rc in
  0 )
    echo "clocks are synchronized"
    ;;
  1 )
    echo "WARNING: clocks are NOT synchronized"
    ;;
  2 )
    echo "CRITICAL: NTPD IS DOWN -- NO STATUS"
    ;;
esac
Cartwig
  • 141
  • 2
  • 2
  • 10
  • When I check, I use `ntpdate -q ` and parse the output to get the actual offset versus that server. This disconnects the "is it good" logic from the script doing the actual data collection so the script doesn't need to be updated or have a parameter changed if we decide to change how tightly a time sync must be in order to be "good" – Steve Bonds Feb 17 '16 at 07:09
  • Is it for Nagios? – Rui F Ribeiro Feb 17 '16 at 09:19

1 Answers1

6

I use ntpq for that.

Here's some snippets and pseudo code.

First, calculate the offset and store it in a var:

ntp_offset=$(ntpq -pn | \
     /usr/bin/awk 'BEGIN { offset=1000 } $1 ~ /\*/ { offset=$9 } END { print offset }')

  1. Server OK when: ntp_offset < 1000

  2. Server unsynchronised when: ntp_offset >= 1000

  3. the check for ntpd is down may be done with different approaches, depending on your OS. For example, use service ntpd status on red hat, centos and similar, and then check the result status on the $? variable.

slm
  • 363,520
  • 117
  • 767
  • 871
Nuno Pereira
  • 175
  • 8
  • 1
    The 0, 1, 2 levels suggest it is a Nagios script, and there is a plug-in for that. – Rui F Ribeiro Feb 17 '16 at 09:19
  • @RuiFRibeiro, actually the command that I execute is remove from our zabbix configuration. – Nuno Pereira Feb 17 '16 at 18:08
  • Thank you, @NunoPereira .isn't there a correlation between ntpstat and ntpq? When I try `ntpstat` the output looks like this: synchronised to NTP server (10.248.181.16) at stratum 3 time correct to within 1010 ms polling server every 64 s However, at the exact same time, executing `ntpq -pn` looks like this: remote refid st t when poll reach delay offset jitter ======================================================= *10.248.181.16 24.56.178.140 2 u 15 64 1 0.261 0.300 0.006 **offset = 0.300** (Sorry I'm unable to format the comment right) – Cartwig Feb 18 '16 at 01:42
  • 1
    Not really, @Cartwig. Short story: `ntpstat` gives the maximum error that your local clock has, while `ntpq -pn` gives what the local peer estimates as the offset to each of the remote peers. I prefer the second, and the values are very different (offset should be much smaller than the "time correct to within" value). Check http://serverfault.com/questions/184257/seemingly-poor-quality-of-ntp-time-synchronization-using-a-gps-clock for more info about both. – Nuno Pereira Feb 18 '16 at 02:19
  • **NOTE:** This may not work without telling ntpq to explicitly use IPv4. - https://unix.stackexchange.com/questions/345778/why-does-ntpq-pn-report-connection-refused – slm Mar 11 '18 at 04:42