[SOLVED] NTP Problem

WilliamS · 04-29-2014, 09:46 AM

ntp always worked perfectly until I installed 14.1 two weeks ago, but does nothing now.
First error noticed was in /var/log/syslog - format error frequency file /etc/ntp/drift
so I deleted the drift file; no more error, but no change.

I check time against WWV with my shortwave radio, and can see the computer is 8 seconds fast. It was 10 fast last night. Can see in gkrellm that the response from timeservers is not happening.

Tried replacing the two restrict lines with restrict from 14.0; no change.

This what I tried so far:

bash-4.2$ su
Password:
bash-4.2# /etc/rc.d/rc.ntpd stop
Stopping NTP daemon...
bash-4.2# ntpdate pool.ntp.org
29 Apr 09:36:53 ntpdate[1397]: no server suitable for synchronization found
bash-4.2# ping -c5 0.ca.pool.ntp.org
PING 0.ca.pool.ntp.org (192.75.12.11) 56(84) bytes of data.
64 bytes from mx2.trentu.ca (192.75.12.11): icmp_seq=1 ttl=53 time=720 ms
64 bytes from mx2.trentu.ca (192.75.12.11): icmp_seq=2 ttl=53 time=691 ms
64 bytes from mx2.trentu.ca (192.75.12.11): icmp_seq=3 ttl=53 time=651 ms
64 bytes from mx2.trentu.ca (192.75.12.11): icmp_seq=4 ttl=53 time=651 ms
64 bytes from mx2.trentu.ca (192.75.12.11): icmp_seq=5 ttl=53 time=648 ms

--- 0.ca.pool.ntp.org ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4549ms
rtt min/avg/max/mdev = 648.587/672.586/720.075/28.536 ms
bash-4.2# /etc/rc.d/rc.ntpd start
Starting NTP daemon: /usr/sbin/ntpd -g
Saving system time to the hardware clock (localtime).
bash-4.2# ps -ef | fgrep ntpd
root 2743 1 0 10:16 ? 00:00:00 /usr/sbin/ntpd -g -p /var/run/ntpd.pid
bash-4.2# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*LOCAL(0) .LOCL. 10 l 16 64 37 0.000 0.000 0.000
ns1.ptpbroadban .INIT. 16 u - 64 0 0.000 0.000 0.000
ntp.lanets.ca .INIT. 16 u - 64 0 0.000 0.000 0.000
euro-shared.oln .INIT. 16 u - 64 0 0.000 0.000 0.000
zero.gotroot.ca .INIT. 16 u - 64 0 0.000 0.000 0.000
bash-4.2# ls -l /etc/localtime-copied-from
lrwxrwxrwx 1 root root 36 Apr 28 02:03 /etc/localtime-copied-from -> /usr/share/zoneinfo/America/Montreal
bash-4.2#

Here is my /etc/ntp.conf

# Sample /etc/ntp.conf: Configuration file for ntpd.
#
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available. The
# default stratum is usually 3, but in this case we elect to use stratum
# 0. Since the server line does not have the prefer keyword, this driver
# is never used for synchronization, unless no other other
# synchronization source is available. In case the local host is
# controlled by some external source, such as an external oscillator or
# another protocol, the prefer keyword would cause the local host to
# disregard all other synchronization sources, unless the kernel
# modifications are in use and declare an unsynchronized condition.
#
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
server 0.ca.pool.ntp.org
server 1.ca.pool.ntp.org
server 2.ca.pool.ntp.org
server 3.ca.pool.ntp.org

#
# NTP server (list one or more) to synchronize with:
#server pool.ntp.org iburst

#
# Drift file. Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
#
driftfile /etc/ntp/drift

#
# Uncomment to use a multicast NTP server on the local subnet:
#multicastclient 224.0.1.1 # listen on default 224.0.1.1
# Set an optional compensation for broadcast packet delay:
#broadcastdelay 0.008

#
# Keys file. If you want to diddle your server at run time, make a
# keys file (mode 600 for sure) and define the key number to be
# used for making requests.
# PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote
# systems might be able to reset your clock at will.
#
#keys /etc/ntp/keys
#trustedkey 65535
#requestkey 65535
#controlkey 65535

#
# Don't serve time or stats to anyone else by default (more secure)
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

#
# Disable the ntpdc -c monlist command, which is insecure and can be used
# to cause a denial of service attack (CVE-2013-5211). Future versions of
# NTP will remove this command.
disable monitor

#
# Trust ourselves. :-)
restrict 127.0.0.1
restrict ::1

I did slackpkg reinstall ntp twice. No joy.

Please advise.

GazL · 04-29-2014, 10:05 AM

Comment out the 127.127.1.0 server and fudge lines. From experience, I've found using the undisciplined local clock reference causes problems with the initial 'large' adjustment ntpd does on startup. Instead, add:

Code:

tos orphan 10    # Assume the guise of a stratum 10 server when there
                 # are no external syncronisation sources available.

BTW, ntp and hwclock in 'localtime' are never a good mix. I'd recommend running your hardware clock on UTC if you're planning on using ntp.

tronayne · 04-29-2014, 11:21 AM

Second GaxL's advice about the hardware clock running UTC. You will need to, as root, execute timeconfig and answer the questions after you have set the hardware clock to correct UTC time (which, if you're on DST, is local time + 4 hours).

One question, though, do you have DNS server addresses in /etc/resolv.conf or are you counting on wireless or wi-fi or a DNS server in your router? The lines above,

Code:

bash-4.2# ntpdate pool.ntp.org
29 Apr 09:36:53 ntpdate[1397]: no server suitable for synchronization found

is a little disturbing (it looks like no DNS server running). However a few lines later you ping and get a response. Does Canada block US addresses? Or try ntpdate 0.ca.pool.ntp.org instead.

About /etc/ntp/drift. You can poke a floating point number into that file to give the NTP daemon a place to start (NTP will update that value over time); as root, try

Code:

echo 0.0 > /etc/ntp/drift

I won't often argue with GazL, but I will on this one (because over the past 20-odd years I've never experienced any problem with NTP by so doing). Your server settings in /etc/ntp.conf file should look like this, with the exception that you change the "0.us.pool.ntp.org" to "0.ca.pool.ntp.org:"

Code:

<introductory text above here>
# disregard all other synchronization sources, unless the kernel
# modifications are in use and declare an unsynchronized condition.
#
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

#
# NTP server (list one or more) to synchronize with:
#server pool.ntp.org iburst
server  0.us.pool.ntp.org
server  1.us.pool.ntp.org
server  2.us.pool.ntp.org
<other stuff below here>

Note that you only need three external servers; NTP figures out whether a server is good or not and will automatically select new candidate servers.

Those local clock lines are for when your Internet connection drops, NPT will synchronize to itself (the system clock) until the Internet connection comes back.

Essentially, you take the stock /etc/ntp.conf file, comment out

Code:

#server pool.ntp.org iburst

and add three lines below that. You do not need to fiddle with anything else in the stock file.

Things you want to do are

Shut down NTP
Put your /etc/ntp.conf file back to "Slackware standard," adding three server lines.
Get your system clock (the software clock) close to the "real" time. You can do that with ntpdate[/I], but don't do that all the time, just once to get it set right.
Get your hardware clock set to UTC.
Execute timeconfig, choose UTC, choose Canada Eastern (so your daylight time switch will occur on the correct date).
Restart NTP

Let NTP run for a minute or so and

Code:

ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*127.127.1.0     .LOCL.          10 l   11   64    1    0.000    0.000   0.000
 138.236.128.36  147.84.59.145    2 u   10   64    1  605.835   -4.965   0.000
 204.9.136.253   129.6.15.29      2 u    8   64    1  1273.00  343.006   0.000
 173.230.158.30  199.102.46.73    2 u    7   64    1  1024.32  182.276   0.000

That shows you that you are synchronized to your local host and that there are three external servers that are candidates for synchronization.

Wait about 5-10 minutes and

Code:

ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.1.0     .LOCL.          10 l   13   64  377    0.000    0.000   0.000
*138.236.128.36  147.84.59.145    2 u    3   64  377  608.084   -7.372 117.718
+204.9.136.253   129.6.15.29      2 u   62   64  377  594.957    6.392 196.707
+173.230.158.30  199.102.46.73    2 u   61   64  377  600.842    9.820 162.101

The asterisk indicates the server you're synchronized to, the plus signs indicate candidates for if and when the synchronized server drops off line or becomes noisy.

By the way, using ntpq -pn avoids DNS look up for servers; it just displays faster.

You might want to check and see that you have the current stable NTP package installed:

Code:

ls /var/log/packagers/ntp*
/var/log/packages/ntp-4.2.6p5-x86_64-5_slack14.1

It goes without saying that there should only be one (either the 32-bit or 64-bit version).

Hope this helps some.

GazL · 04-29-2014, 12:27 PM

Quote:

Originally Posted by tronayne

I won't often argue with GazL, but I will on this one (because over the past 20-odd years I've never experienced any problem with NTP by so doing).

I was speaking from my own personal experience. Here take a look at this example.

First with the 127.127.1.0 local reference enabled:

Code:

root@ws1:~# date
Tue 29 Apr 17:45:57 BST 2014
root@ws1:~# date 04291300
Tue 29 Apr 13:00:00 BST 2014
root@ws1:~# date
Tue 29 Apr 13:00:06 BST 2014
root@ws1:~# ntpd -c /etc/ntp.conf_with_localclock -g
root@ws1:~# date
Tue 29 Apr 13:00:41 BST 2014
root@ws1:~# ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.1.0     .LOCL.          10 l   14   64    1    0.000    0.000   0.000
+80.5.182.144    62.119.40.98     2 u    3   64    1   14.526  1716993   0.272
*94.228.40.3     195.66.241.10    2 u    2   64    1   16.976  1716993   0.380
+5.77.53.133     91.189.94.4      3 u    1   64    1   17.012  1716993   0.503
root@ws1:~# date
Tue 29 Apr 13:01:13 BST 2014
root@ws1:~# # wait a few minutes.
root@ws1:~# date     
Tue 29 Apr 13:04:09 BST 2014
root@ws1:~# ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.1.0     .LOCL.          10 l  221   64   10    0.000    0.000   0.000
+80.5.182.144    62.119.40.98     2 u   17   64   17   14.526  1716993   0.343
*94.228.40.3     195.66.241.10    2 u   19   64   17   16.976  1716993   0.709
+5.77.53.133     91.189.94.4      3 u   18   64   17   16.424  1716993   0.712

And then with it commented out and using tos orphan as I do:

Code:

root@ws1:~# pkill ntpd
root@ws1:~# ps -ef |grep [n]tpd
root@ws1:~# date
Tue 29 Apr 13:04:54 BST 2014
root@ws1:~# ntpd -c /etc/ntp.conf -g
root@ws1:~# date
Tue 29 Apr 13:05:22 BST 2014
root@ws1:~# date
Tue 29 Apr 13:05:33 BST 2014
root@ws1:~# date
Tue 29 Apr 13:05:48 BST 2014
root@ws1:~# date
Tue 29 Apr 13:05:58 BST 2014
root@ws1:~# date
Tue 29 Apr 13:06:07 BST 2014
root@ws1:~# date
Tue 29 Apr 13:06:12 BST 2014
root@ws1:~# date
Tue 29 Apr 13:06:18 BST 2014
root@ws1:~# date
Tue 29 Apr 13:06:21 BST 2014
root@ws1:~# date
Tue 29 Apr 13:06:23 BST 2014
root@ws1:~# date
Tue 29 Apr 17:52:35 BST 2014
root@ws1:~# ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*80.5.182.144    62.119.40.98     2 u   55   64    7   13.362   -3.209   3.385
+193.47.164.28   192.93.2.20      2 u   55   64    7   25.037    3.653   0.666
+85.119.80.232   94.228.40.3      3 u   56   64    7    9.150   -2.326   0.995

Without the local clock reference, the time syncronises within a minute of starting ntpd, with it, it is still wrong several minutes later, and if I remember rightly (it's been a while since I was playing with this), it never manages to syncronise.

I think I came to the conclusion that it was only ever using the local clock reference for the initial 'large' adjustment, which was always offset +0.0000, and so never adjusted local system time, and from that point onward the times it got from the ntp servers were too far adrift of local system time to be considered valid.

The workaround, if you want to leave the local clock reference in your config file, is to always ensure you do a ntpdate prior to starting ntpd, so that the servers are within a reasonable offset when ntpd starts.

Anyway, that's why I now recommend removing the local clock reference these days, though if your clock is always reasonably in-sync you're never likely to see this behaviour anyway.

mlslk31 · 04-29-2014, 12:38 PM

If in doubt, lose the restrict lines and add things back once you get time service back. Also, be sure that port 123/udp hasn't been firewalled off.

Really, though, the others here are correct. FWIW, the LOCAL clock is supposed to be deprecated in favor of ntpd's orphan facility.

You do have a shortwave radio, though. Have you thought of using it with the CHU audio (127.127.7.x) or WWV audio (127.127.36.x) drivers? If you can get one of them going, you can have good time while working out the rest of the issues. Should you need to recompile ntpd in order to use them, I think the ./configure flags will include "--enable-WWV --enable-CHU --enable-AUDIO-CHU". You can add them directly to the ntp.SlackBuild file that comes with Slackware's ntpd source code.

If you remove the NTP drift file altogether, it will take longer for ntpd to figure out the drift rate and therefore write the drift file. All of those .INIT. flags in your ntpq output makes me think that the issue is something else, though. Either that or you didn't let things ntpd for long enough...

There are more things to check, but this seems like a good start.

tronayne · 04-29-2014, 01:54 PM

The only problem with the examples is how the NTP daemon gets started in the first place and how it keeps things synchronized.

The hardware clock, set to within 1,000 seconds of UTC, is read at boot and initializes the software (system) clock. If you're not withing 16 minutes, it ain't gonna synchronize, come hell or high water. It's easy enough, if it doesn't synchronize within about 5- 10 minutes of run, to stop the daemon and use ntpdate (or, better, ntpd -g -q) to set the system clock to local time, then restart NTP (and it should then synchronize with an external server). At system shutdown, the synchronized time is written to the hardware clock.

All that works if the CMOS battery isn't dead (or you're just rebooting). Dead CMOS battery, well, same thing happens if your electric wristwatch battery dies (and you can be off by days depending upon how long the system has been turned off and you really don't want that to happen). The -g argument to ntpd will allow the time to be set to any value without restriction, so Bad Things Can Happen if the CMOS battery is dead (imagine all your time stamps being set to five days ago, for example).

Generally, it's not a good idea to delete /etc/ntp/drift, which contains the pfudge pfactor that's used to "walk" the the system clock into synchronization. On a newly installed system I always punch 0.0 into that file rather than waiting for the NTP daemon to write to it after some, fairly long, period of synchronized time.

Too, ntpdate is considered obsolete; ntpd -g -q server should be used instead to initialize the system clock to the correct time (ntpd sets the time and quits). The -x option can be used in conjunction with the -q option, but:

Quote:

Normally, the time is slewed if the offset is less than the step threshold,
which is 128 ms by default, and stepped if above the threshold. This option
sets the threshold to 600 s, which is well within the accuracy window to set
the clock manually. Note: Since the slew rate of typical Unix kernels is
limited to 0.5 ms/s, each second of adjustment requires an amortization
interval of 2000 s. Thus, an adjustment as much as 600 s will take almost
14 days to complete. This option can be used with the -g and -q options.
See the tinker configuration file directive for other options. Note: The
kernel time discipline is disabled with this option.

Probably don't want to do that.

The timeconfig utility should be used to define the hardware clock as UTC and set the system location (country, region). The Powers that Be seem to have decided that hardware clocks should be UTC (and, frankly, that's a good idea in any event); keep in mind that when the system is rebooted or shut down that the synchronized time from the system clock is written to the hardware clock, then read back from the hardware clock to set the system clock on boot. Hardware clocks are, any more, fairly accurate. System clocks are notorious for drifting all over the place without something (like NTP) keeping them on time (within milliseconds after NTP has been running for a few days or weeks). I remember a couple of boxes that drifted about 10 minutes every 4 hours before I installed NTP to bring them into synchronization (that took days because of the kernel tweaks that NTP does).

Other than buying a (expensive!) GPS or radio clock, NTP is the best bet for Pretty Good Timekeeping.

I serve all the components that have NTP compatible clocks from one server on my LAN and have done so since, cripes, the mid- to late 1980s or so (them were the days). Can't recommend it highly enough.

Hope this helps some.

GazL · 04-29-2014, 04:14 PM

Quote:

Originally Posted by tronayne

Too, ntpdate is considered obsolete; ntpd -g -q server should be used instead to initialize the system clock to the correct time (ntpd sets the time and quits).

Actually, I don't think you can pass the server on the command line like that (or at least, I've never managed to get it to work). When I've been playing with this, it seems that 'ntpd -q' relies on the server definitions in the ntp.conf, however, if you have "orphan mode" enabled in the config file then "ntpd -q" complains about "no servers", and if you have the local clock reference in there, it always returns an offset of +0.0000 and you still don't get a time adjustment.

So, it seems you either need to maintain an alternative config file without either of those options enabled specifically for use with something like ntpd -q -g -c /etc/ntp-quit.conf, or stick with the deprecated 'ntpdate', or alternatively use 'sntp -s <server>' instead.

Each approach likely has its pros and cons.

Well, I think that's about exhausted my knowledge on ntpd.

WilliamS · 04-29-2014, 04:18 PM

I substituted tos orphan 10 for the fudges, commented out 3 of the restrict lines leaving only restrict 127.0.0.1 and will wait and see what happens.

WilliamS · 04-29-2014, 11:41 PM

Commenting out lines did no good at all.

Tronayne, content of /etc/resolv.conf is
# Generated by dhcpcd from eth0
# /etc/resolv.conf.head can replace this line
nameserver 192.168.175.250
nameserver 192.168.175.251
# /etc/resolv.conf.tail can replace this line

Then: # ntpdate 0.ca.pool.ntp.org
29 Apr 23:38:22 ntpdate[13055]: no server suitable for synchronization found

and
# ls /var/log/packages/ntp*
/var/log/packages/ntp-4.2.6p5-i486-5_slack14.1

I'm thinking that ntp always worked before 14.1, I always did the servers and driftfile and commented out the fudge, as others, and nobody else complains.
So I intend to reinstall 14.1 from a different DVD.

irgunII · 04-30-2014, 08:12 AM

Have you made sure you've upgraded the ntp? There was one for it a little earlier this year IIRR. I can't remember if it was for security reasons or otherwise though. ftp://ftp.slackware.com/pub/slackwar..._slack14.1.txz

As for using ntp, I've never had any problems myself (unless of course I'm simply and completely not understanding what's going on here, which would not be beyond believable, heh).

I have *always* used local time since the gmt thing only confuses me or I forget that I'm on it and think I've screwed something up by seeing the time and date and it's not really 'local' time.

As root (su -) I just do:

Code:

sntp -s north-america.pool.ntp.org

and it will change the clock on the taskbar if necessary for me. Again, sorry if I've completely misunderstood the problem and gave a simpletons simple try at helping, heh.

tronayne · 04-30-2014, 08:25 AM

Quote:

Originally Posted by GazL

Actually, I don't think you can pass the server on the command line like that (or at least, I've never managed to get it to work).

Yup, you're right, you can pass a sever to ntpdate, but ntpd will use the content of /etc/ntp.conf.

I'm easily confused sometimes!

GazL · 04-30-2014, 08:32 AM

I didn't misunderstand your meaning tronayne, what I meant was ntpd complains when you try and specify a server on the command line like that:

Code:

root@ws1:~# ntpd -q -g uk.pool.ntp.org
ntpd: Command line arguments not allowed
ntpd - NTP daemon program - Ver. 4.2.6p5
USAGE:  ntpd [ -<flag> [<val>] | --<name>[{=| }<val>] ]...

A simple "ntpd -q -g" will work, but only if you have neither orphan mode, or the local clock reference defined in your config file.

mlslk31 · 04-30-2014, 09:21 AM

You could reduce your ntp.conf to this...

Code:

pool ca.pool.ntp.org

...and if it works, great! If not, leave it like that and start looking at other things. Again, be sure that you can reach out to the Internet on port 123/udp. After reading this thread several times, I wonder what the network-related files looked like when everything worked. If the old settings are lost, I'm not sure how a full reinstall would help. I've used DHCP only for PXE booting, so someone else will have to point out the subtle nuances of networking with ntpd.

tronayne · 04-30-2014, 09:34 AM

This was accidental double-posted.

tronayne · 04-30-2014, 09:40 AM

Quote:

Originally Posted by WilliamS

I substituted tos orphan 10 for the fudges, commented out 3 of the restrict lines leaving only restrict 127.0.0.1 and will wait and see what happens.

Seriously, take the orphan thing out of your /etc/ntp.conf and make it look like this:

Code:

<comment lines above here>
# disregard all other synchronization sources, unless the kernel
# modifications are in use and declare an unsynchronized condition.
#
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

#
# NTP server (list one or more) to synchronize with:
#server pool.ntp.org iburst
server  0.ca.pool.ntp.org
server  1.ca.pool.ntp.org
server  2.ca.pool.ntp.org

#
# Drift file.  Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
#
driftfile /etc/ntp/drift

For right now, tos orphan may not be a Real Good Idea; you can go read information about orphan mode at http://support.ntp.org/bin/view/Support/OrphanMode. I will admit that I don't totally understand precisely what the difference is between an end-user (such as you, me, and most other folks that don't serve time to the Internet) using an undisciplined local clock (as in the above example) and orphan mode which is mostly about preventing reflected denial of server (DRDoS) attacks. I'm going to experiment on one of my servers and see what's what, but, for right now, I'd go with tried and true "traditional" method to get going and fiddle and twiddle later. I only serve time to my LAN, not the outside world (mainly because nobody can get to my servers due to restrictions imposed by HughesNet).

This is the default /etc/ntp.conf file delivered with ntp-4.2.6p5, the current stable version from Slackware stable:

Code:

# Sample /etc/ntp.conf:  Configuration file for ntpd.
#
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available. The
# default stratum is usually 3, but in this case we elect to use stratum
# 0. Since the server line does not have the prefer keyword, this driver
# is never used for synchronization, unless no other other
# synchronization source is available. In case the local host is
# controlled by some external source, such as an external oscillator or
# another protocol, the prefer keyword would cause the local host to
# disregard all other synchronization sources, unless the kernel
# modifications are in use and declare an unsynchronized condition.
#
server	127.127.1.0	# local clock
fudge	127.127.1.0 stratum 10	

#
# NTP server (list one or more) to synchronize with:
#server pool.ntp.org iburst

#
# Drift file.  Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
#
driftfile /etc/ntp/drift

#
# Uncomment to use a multicast NTP server on the local subnet:
#multicastclient 224.0.1.1		# listen on default 224.0.1.1
# Set an optional compensation for broadcast packet delay:
#broadcastdelay	0.008

#
# Keys file.  If you want to diddle your server at run time, make a
# keys file (mode 600 for sure) and define the key number to be
# used for making requests.
# PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote
# systems might be able to reset your clock at will.
#
#keys		/etc/ntp/keys
#trustedkey	65535
#requestkey	65535
#controlkey	65535

#
# Don't serve time or stats to anyone else by default (more secure)
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

#
# Disable the ntpdc -c monlist command, which is insecure and can be used
# to cause a denial of service attack (CVE-2013-5211). Future versions of
# NTP will remove this command.
disable monitor

#
# Trust ourselves.  :-)
restrict 127.0.0.1
restrict ::1

If you edit the server section to

Code:

#
# NTP server (list one or more) to synchronize with:
#server pool.ntp.org iburst
server	0.ca.pool.ntp.org
server	1.ca.pool.ntp.org
server	2.ca.pool.ntp.org

(and don't touch anything else) you will probably have a usable NTP.

I would suggest that you

Stop the NTP datmon (/etc/rc.d/rc.ntpd stop)
Make a back up of your existing /etc/ntp.conf; e.g., cp /etc/ntp.conf /etc/ntp.conf.bak
Copy-paste the above ntp.conf content into /etc/ntp.conf
Edit the above serer line into that file
Execute either ntpdate 0.ca.pool.ntp.org or ntpd -g -q to set the clock
Start the NTP daemon with /etc/rc.d/rc.ntpd start

If you execute /usr/sbin/ntpq -pn right away you should see that you're synchronized to 127.127.1.0 .LOCL.

Wait five- to ten minutes and execute ntpq again and you should see something similar to

Code:

/usr/sbin/ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.1.0     .LOCL.          10 l  42m   64    0    0.000    0.000   0.000
*138.236.128.36  147.84.59.145    2 u   75  128  377  641.617    3.720 161.060
+204.9.136.253   129.6.15.28      2 u   37  128  377  616.774    3.755  52.864
+173.230.158.30  199.102.46.73    2 u   90  128  377  609.258  -15.161 165.601

indicating that you're synchronized.

You may want to check that your system is configured so that the hardware clock is set to UTC:

Code:

fgrep UTC /etc/* 2>/dev/null   
adjtime:UTC
hardwareclock:UTC

Both those files should appear in the list.

Kernel developers and NTP developers appear to want your hardware clock on UTC; personally, I think that's probably for the best. Others prefer both the hardware and software clocks to use local time. That really should not be a problem, but it might sometime in the future. Either way, NTP will synchronize time for you.

One other thing: if you execute ntpdate when the NTP daemon is running, you get

Code:

ntpdate
30 Apr 10:29:54 ntpdate[774]: no servers can be used, exiting

Look familiar? Make sure the daemon is not running:

Code:

ps -ef | grep ntp
root       540     1  0 09:33 ?        00:00:00 /usr/sbin/ntpd -g -p /var/run/ntpd.pid
root       780   758  0 10:32 pts/0    00:00:00 grep ntp

If you see that, and you have executed /etc/rc.d/rc.ntpd stop, you've got a phantom daemon running and you need to kill it by hand:

Code:

kill -9 540

would do that for the above example (540 is the PID of the running process, you're will vary).

Hope this helps some.