Your hosting provider is blocking ntp packets. This heavy handed approach has been implemented by some ISPs in response to the DDoS attacks. You can see that ntpdate is sending the packets fron the ntpdate -vd :
transmit(91.189.94.4)
transmit(91.189.89.199)
transmit(91.189.94.4)
transmit(91.189.89.199)
I would contact your ISP and ask if they are blocking external ntp requests and if they have a local server that you can use for time sync.
There are a couple more obscure possibilities but it is tough to rule them out since you have not posted any logs from syslog.
The problem was resolved, the system works now. I do this summary for myself and any others who need to setup an offline NTP server (again).
The actual problem seemed to be that the experimentation with the broadcast mode broke the ntpd on the server, it again worked on another server restart. Why it did not work when I followed the above given posts I am not really sure.
Backgound
Part of the problem was that I did not understand how NTP works and what I was doing. Neither man page nor the server guide 16.04 gave a simplified overview on the different computers work together.
First, NTP client and server is misleading. Its always the same program, the NTP deamon, "ntpd". It must be installed on every computer on the local network for the time synchronisation to work. I did not check about the windows clients yet but I am sure there is a version for them somewhere as well (please comment if you have info about it - build in functions would be preferred).
The offline system would work on system clocks only. Its beneficial to use several system clocks, not only the main server, because each clock adds to reduce the time drift. In other words, one clock would make all computers synchronised, but absolute time in more stable and precise when more clocks are considered. From what I read 4 should be a good number.
NTP can act as server and as client at the same time. The default configuration file does not really have a configuration section for the server role. As simple model, each ntpd instance is a client which gets time information from somewhere by regular polling it. Either polling another ntpd or polling the local onboard clock. It becomes a server when is answers polls from others.
For example a network connected by a proxy server to the internet. That proxy server would run ntpd to poll several internet NTP servers and thus snyc its own time to them. When all local clients poll that proxy server for its (synchonised) time and it starts answering the polls, it becomes and NTP server itself. Out offline case is exactly that, except the online servers are replaced by the onboard clock.
Configuration
For the setup the /etc/ntp.conf file must be edited. The default is quite full of stuff. I deleted all except:
# this is the IP or name of the local networks NTP server. This line
# should be commented out on the server
server 192.168.1.111
# this enables checking the local clock. Do not change that IP values!
server 127.127.1.0
fudge 127.127.1.0 stratum 10
# this lines are required to run the ntpq -p command to verify the
# function of the system
restrict 127.0.0.1
restrict ::1
The server in that example has the IP 192.168.1.111. This config can be the same for all PCs on the network. Only comment out the local clock section on clients which are not laptops. The line should be kept on laptops and other devices that may operate off the net for some time. The first server section should be commented out on the server.
After editing restart the service with the start/stop script
sudo /etc/init.d/ntp restart
For checking run
ntpd -p
its a bit shorter than the version in the question and gives the same output. There is a * before the clock line to indicate that its being used.
Here the output for a working server:
remote refid st t when poll reach delay offset jitter
==============================================================================
*LOCAL(0) .LOCL. 2 1 6 64 377 0.000 0.000 0.000
The when column is counting up, the reach is anything >0.
Here the output for a working client:
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.1.111 LOCAL(0) 3 u 31 64 377 0.206 -5.900 0.654
If you yet refid=.INIT. it does not work. The numbers would differ obviously. The clients should not show 0.000 0.000 0.000 values.
An output for a client with additional configured fall back clock (note its not being used right now - no *):
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.1.111 LOCAL(0) 3 u 31 64 377 0.206 -5.900 0.654
LOCAL(0) .LOCL. 8 l 6 64 1 0.000 0.000 0.000
added infos
The default config describes a broadcast send and a broadcast receive option. Do not activate this for normal operation. It is not required to get the system going and to configure client and server.
If anything gets stuck do not only restart the service, but reboot fully. Even an ubuntu server.
When the system did not run, I noted that ps -e |grep ntpshould 2 'ntpd' processes. The pair could be started and stopped consistently. The running version only showed one on each computer.
There are other restriction options and logging option from the default config file that might be useful. Did not test them.
Hopefully that becomes useful at some time. If you have corrections, please comment, I will try to update the answer.
CatMan
PS: Big thanks to Ken Mollerup, whose comments lead me to a better understanding of the NTP system.
Best Answer
Here's a good how-to from Ubuntu forums: http://ubuntuforums.org/showthread.php?t=862620
Flagrant copy-pasta:
HOWTO: Set Up an NTP Server
This tutorial describes how to set up your machine as a local Network Time Protocol (NTP) server and/or how to use the NTP daemon to regularly maintain an accurate system time.
What is NTP?
The Network Time Protocol (NTP) is a protocol designed for accurately synchronizing local time clocks with networked time servers. The NTP network of time servers is set up as a hierarchical manner, such that any user can enter the system as a server at some level (see the Wikipedia page for more details).
The NTP hierarchy is separated into different levels, called clock strata. The most accurate level, Stratum 0, is reserved for atomic clocks, etc. The next level, Stratum 1, is generally used by networked machines locally connected to the Stratum 0 clocks. Stratum 2...15 are NTP machines that are connected, in turn, to lower level clocks and each other.
This guide describes how to synchronize accurately with Stratum 1 and 2 machines, and maintain as accurate of system clock as possible throughout the day. Sections are also included on how to allow your machine to operate as a Stratum 2/3 server for other machines on your local network.
Do I have to make an NTP server?
No... absolutely not! If you're satisfied with the clocks on your network having some unknown difference from the standard time (and each other), then you do not have to set up an NTP server. I set one up on my laptop in order to synchronize multiple machines on a local network within < 1 ms for a bioengineering experiment. There are various other advantages, in addition, which are described below.
Motivation:
Regularly, unmodified Ubuntu boxes use ntpdate (
/usr/sbin/ntpdate) to synchronize the clock periodically with some external time server. This approach synchronizes the clock with a coarse resolution (typically once a day).Computer clocks are imperfect, and will drift from the (correct) time server during the day. Furthermore, drift rates in the clocks of different computers differ, such that by the end of the day significant differences may exist between different locally networked machines, which may interfere with certain operations (for instance, ever have a makefile complain when moving source code among different machines?).
It is possible to run the NTP daemon locally on a machine on your network. This has multiple advantages: first, the NTP daemon gradually "learns" the drift rate of your local machine, and can correct for it throughout the day. Synchronization with upper level time servers takes place multiple times a day, and many different time servers may be used simultaneously to make the synchronization more accurate. In this way, the NTP daemon acts as an accurate time client, keeping your system clock as close to the the standard time as possible.
In addition to maintaining an accurate system clock, the NTP daemon allows a machine on your network (if you would like) to operate as an NTP time server. Doing so will allow other machines on your local network to synchronize with your LAN time server in a very quick and accurate manner, since network latency is minimized. In this way, the differences in clocks between machines on your network is kept as minimal as possible. Mac, and even Windows boxes are also able to synchronize with an NTP server, should you set one up.
There are other, less personal, motivations for setting up a machine as an NTP server. First, doing so may decrease the strain on higher level NTP servers, since other machines on your LAN may synchronize with a locally established time server. Also, ntpdate has been deprecated in favor of using the -q flag for ntpd (which mimics its functionality). Thus, even if you do not want to run ntpd constantly in the background, ntpdate will eventually be replaced with ntpd, so you may want to become familiar with it now
How to Maintain an Accurate System Clock with ntpd
First, install the NTP daemon (ntpd):
As was previously mentioned, ntpd can act both as a client (synchronizing your system time) and as a server (providing accurate time for other machines).
Optionally, you may also want to remove the previous (deprecated) time synchronization program, ntpdate. Perhaps it may be wiser to do so after you have ntpd working
The configuration file for ntpd is located at
/etc/ntp.conf. The default Ubuntu file probably requires some modification for optimal performance.The first section you may want to modify is the list of servers to synchronize with. The default section probably looks as follows:
In order to get the most accurate time possible, it is preferable to communicate with multiple different NTP servers, and keep them as close to your physical location as possible. There are various different server lists online, probably the best is located here. There is some debate over the proper number of servers to use. One is better than two, and three or more probably is a good idea, so long as you don't go too overboard. An example of a few time servers that I used follows:
Once a few good servers have been found, add them to the list, putting
'iburst'after the most promising one. For instance:This will cause ntpd to synchronize very quickly with this server after starting up. Otherwise, ntpd will slowly tend to drift towards agreement with the server list (as is its nature), and it may take 15-20 minutes to synchronize well enough to act as a time server for the rest of your network.
Also, add a few extra lines to the bottom of your servers list to provide your current local time as a default should you temporarily lose Internet connectivity:
This will prevent any nastiness if you're running ntpd on a laptop or other machine with intermittent periods of disconnection from the Internet.
All in all, the server list should look similar to the following (this is mine, your servers will probably be different):
Now that you have a proper server list in your
/etc/ntp.conffile, it is time to run the daemon and see if you synchronize properly! Make sure you have an active Internet connection, and then run:Next, monitor your system log to see if you synchronize with a time server:
In about 10-15 seconds (or up to 15-20 minutes if you forgot to put 'iburst' after your favorite server), you should see something like the following in your system log:
If this message never comes, you have not yet properly synchronized with the NTP server network. Check the list of NTP peers you are communicating with using the following:
If the 'delay', 'offset', and 'jitter' fields are non-zero and you haven't synchronized, it probably means that you just need to wait a while. Check again that you've inserted the 'iburst' argument to your servers list! My peers, for reference, look something like the following:
Once ntpd is running and is synchronized with the time servers you have selected, you may set it up in order to act as a time server for other machines. To do so, add a section like the following to
/etc/ntp.conf:Once you've set up an NTP server using steps 1-4, you can synchronize the other machines on your network with your server in various manners. I outline a couple of them below:
ntpd:
If you have ntpd installed on another machine, you can use your first server in the servers list of your ntp.conf file, or can synchronize one time with the -q option, as follows:
ntpdate:
If you still have ntpdate installed on another machine, you may use it to synchronize with your server as follows:
Note: if you are running ntpd on a machine and for some reason still want to use ntpdate to set the time, you must use the -u option.
Windows:
Windows machines use a simplified version of NTP called Simple Network Time Protocol (SNTP), and can synchronize with NTP servers. In order to synchronize with your new server, double click on the time and go to the "Internet Time" tab. Put the IP address of your server in the "Server" field. I have attached a screenshot of Windows XP synchronizing with a LAN time server, should anybody be interested.
That's it! The entire process is not hard, but can be confusing to somebody who hasn't dealt much with the NTP network before. I hope this helps! Let me know if you have any problems setting up your server.
Mike
Links
I found the following links helpful... you may, too!