How to check if NTPD updates machine's time successfully using shell?

Using a script to monitor ntpd is not commonly done. Usually a monitoring tool like nagios or munin is used to monitor the daemon. The tool can send you an alert when things go wrong. I have munin emailing me if the offset exceeds 15 milliseconds.

Normally, you should use an odd number of servers so that the daemon can perform an election among the servers if one goes off. Three is usually adequate, and more than five is excessive. Clients on your internal network should be able to get by with one internal server if you monitor it. Use legitimate servers or your ISPs NTP or DNS servers as clock sources. There are public pools as well as public servers.

ntpd is self tuning and you should not need to adjust it once it is configured and started. With recent ntpd implementations you can drop use of ntpdate entirely as they can do the initial setting of the date.

The following script will parse the offsets in the output of ntpd and report an excessive offset. You could run it from cron to email you if there are problems. The script defaults to alerting on an offset of 0.1 seconds.

#!/bin/bash
limit=100   # Set your limit in milliseconds here
offsets=$(ntpq -nc peers | tail -n +3 | cut -c 62-66 | tr -d '-')
for offset in ${offsets}; do
    if [ ${offset:-0} -ge ${limit:-100} ]; then
        echo "An NTPD offset is excessive - Please investigate"
        exit 1  
    fi  
done
# EOF

To answer the first question, ntpdate usually tells you what it did, or maybe did not do.

[root@flask rc.d]# ntpdate dagoo
12 Aug 10:04:03 ntpdate[20585]: adjust time server 10.0.0.15 offset -0.042285 sec

The NTP daemon, ntpd, runs constantly, and asks NTP servers (usually configured in /etc/ntp.conf) for the time every so often. You shouldn't have to run your script every 5 minutes. ntpdate should bring the machine into near synch with the server, and ntpd will run in the background and keep it in synch. You don't set the interval that ntpd tries, it adjusts the interval based on how it perceives the local clock drifts from the servers, and the quality of the connections to the servers.

You can use a program named ntpdc to see what ntpd keeps as information:

1 % ntpdc 
ntpdc> peers
     remote           local      st poll reach  delay   offset    disp
=======================================================================
*min-time-01.ine 10.0.0.15        1 1024  377 0.07047  0.014673 0.14360
=dns-01.esd189.o 10.0.0.15        2 1024  377 0.07587  0.022277 0.13660
ntpdc>

I think that the number you typically have an interest in is "offset", that's the number of seconds your local clock is off from the server's clock.

As the man page for ntpdc states for the "peers" command :

the current estimated delay, offset and dispersion of the peer, all in seconds.

So, clearly, the "offset" is in seconds.

It appears that ntpdc is deprecated, replaced by ntpq. ntpq has a "peers" interactive command, that does give "offset" in milliseconds. My Redhat server has both ntpdc and ntpq, so you'll need to be careful.

Use ntpstat.

myserver # ntpstat
synchronised to NTP server (10.89.160.13) at stratum 4
   time correct to within 124 ms
   polling server every 1024 s