Using NTP to sync time on Debian

Keeping your Debian system's date and time accurate is easy to do using NTP.

Synchronize watches

Having an accurate clock on your VPS is usually a good thing. It ensures the time stamps in emails sent from the machine are correct, and it's especially helpful when you need to look at the logs from a particular time of day.

If you are running a kernel from our repository that is older than you shouldn't need to do anything to keep your server at an accurate time. The VPS will sync with the hardware clock, which is syncing from an NTP server itself.

Newer kernels, on the other hand, use a scheme that actually prevents the VPS from talking to the hardware clock (the "pvops" kernels, for the curious and technical-minded). This means that if you aren't occasionally setting the system clock yourself the time will slowly drift away from a perfectly accurate setting.

Network time protocol

That's where the network time protocol (NTP) comes in. NTP lets you automatically sync your system time with a remote server.

Setting up an NTP server to regularly adjust your machine's clock is pretty easy by default. It's also possible to make it a bit more complicated if you need your clock accurate down to the millisecond instead of just to the second.


The first thing to do is install the NTP server. Grab the package by running:

sudo aptitude update
sudo aptitude install ntp

Start the service

To make sure the NTP service starts after installing it, run:

sudo /etc/init.d/ntp start

As is usual for Linux services, you can stop or restart the NTP service by running the above command with "stop" or "restart" sent as the argument instead of "start".


Most people just want to get NTP running and don't need to sync their clock to pinpoint, millisecond-level accuracy.

For those people: You're done. You can actually stop now. When you installed NTP it set you up with some default servers to sync with. From now on NTP will sync your clock automatically.

Congratulations on a job well done!

If you want to use NTP to sync several of your own machines with each other, or want to choose NTP servers other than the defaults, read on.

The ntp.conf file

The NTP configuration file can be found at:


There are a few settings that can be changed in there, but for most people the only settings of interest would be any "server" entries. The default for Debian looks like:

# maps to about 1000 low-stratum NTP servers.  Your server will
# pick a different set every time it starts up.  Please consider joining the
# pool: 
server iburst dynamic
server iburst dynamic
server iburst dynamic
server iburst dynamic

With more than one "server" entry your NTP server will query all servers and only select a time that a majority of the polled servers will agree on. This basically means that with three or more servers your clock will be more accurate than if it just uses one.

If you add the "iburst" option after the server address it can speed up the NTP time sync by a bit. It's usually a good idea to use it, but not essential.

The "dynamic" option tells NTP that it can try a configured server again later if it's unavailable at some point. The option is useful when NTP is running on a machine that doesn't always have access to the Internet, but is not necessary on a machine with a dedicated connection.

Syncing multiple servers

If you have more than one machine to sync it works best if you designate one to be your "master" NTP server. Let that one server connect to an outside NTP server, then have the other machines sync to the master.

The advantages of this setup are a reduced number of outgoing connections and a guarantee that all of your machines will have their time set to the exact same value. Configuring this kind of setup just requires changes to the "server" settings in the ntp.conf files on each machine.

On the master machine you would set up any external servers you want to use. For example, if you wanted to use the NTP pool servers (more on that later) you could set the "server" values in the master's ntp.conf file to:

server iburst
server iburst
server iburst
server iburst

Then on every other machine for which you want to sync the time point the ntp.conf to your master server. If your master server were going to be "", you would alter the ntp.conf files on the secondary machines so the server entries would all be:

server iburst

After setting the server parameters and making sure iptables won't block connections to your main NTP server, just restart the NTP services on each machine to get them syncing.

Adjusting iptables

NTP uses UDP port 123 to conduct its business, either connecting out to another NTP server or accepting incoming connections. If you have iptables filtering incoming traffic on the main NTP server in your cluster you'll need to open port 123 to UDP traffic to allow the other servers to connect to it.

You can open port 123 for UDP traffic with the following arguments for iptables:

-I INPUT -p udp --dport 123 -j ACCEPT
-I OUTPUT -p udp --sport 123 -j ACCEPT

Choosing an NTP server

When syncing one or more machines via NTP you'll want at least one of them to set their time from a reliable external server. There are many public servers out there that are either synced directly from an atomic clock (guaranteeing an absolutely accurate time), or are synced from another server that syncs to an atomic clock.

Public NTP server lists

The best source for lists of public NTP servers is the NTP Servers WebHome at the main NTP site. When you visit that site you'll see a description of the servers available, and in the sidebar should be links to three "levels" of NTP servers: Primary, secondary, and pool. How accurate you need your servers to be will determine what type of server you'll want to sync from.

NTP pool servers

For most users the "pool" servers are the best choice. Pool servers are machines that have volunteered to make their NTP server available to the public. They typically sync from a secondary NTP server so their time is accurate, but not necessarily accurate to the nearest millisecond.

Most users don't need to be accurate to the nearest millisecond, they just want to know what time it is. So unless you absolutely know you need pinpoint accuracy, use the pool servers.

Using the NTP pool servers is as easy as setting the servers entries in your ntp.conf file to:

server iburst
server iburst
server iburst
server iburst

If you want to make sure you only connect to pool servers in your own country or region visit the pool servers page for more specific addresses. For most people the above entries will be more than sufficient. Those addresses rotate among a huge list of volunteer NTP servers worldwide so the load on any one machine never gets too great.

For that matter, once you've set up your NTP server, if you want to contribute to the NTP pool you can get details on how to do so from the pool web site.

Primary and secondary servers

The other two tiers of NTP servers are primary and secondary servers.

A primary server is one that gets its time directly from an atomic clock (or from GPS satellites, which use atomic clocks). Atomic clocks are expensive so there aren't a lot of primary servers. You won't want to use a primary server unless you're looking for extreme scientific accuracy.

A secondary server usually gets its time from a primary server. If you want accuracy down to the millisecond level, having three secondary servers in your ntp.conf will usually do nicely.

Selecting either list from the NTP Servers WebHome will let you see what public servers are available in either tier. Before selecting and using a server check the details for that server as follows:


The "ISO" column lists the country of origin of that particular server.


The AccessPolicy field tells you what the access policy is for that server. "Open Access" means the server can be used by the public, subject to any notification requirements the server has.


The "Notify?" field for secondary servers lists the preferences of that server's administrator regarding whether or not they be notified before you sync with their NTP server. Admins who want to be notified are usually trying to manage the traffic to their server, so be sure and respect their wishes regarding notification.

Note that primary servers are always considered as requesting notification before use.

Service Area

If you've selected a primary or secondary server you want to use, click its hostname in the list to look at further details for that server.

Among the details listed is the "ServiceArea" field. That describes the geographic or demographic group they intend to serve. If that field is "Public" then you do not have to be in a particular region to use the server. If they list a more specific service area be sure to respect the server administrator's wishes in that regard.

Testing with ntpdate

Before using an external NTP server to sync your time you should make sure you can actually connect to the server from your machine. Fortunately there's a tool for that named "ntpdate".

To use it you might first need to install ntpdate:

sudo aptitude install ntpdate

The ntpdate command will sync your clock with an NTP server. It's similar to what the NTP server does on a regular basis.

You usually shouldn't use ntpdate for anything other than testing purposes unless you want to make sure your clock only syncs at particular times of day (by using cron to run ntpdate just at those times). Otherwise you're better off running the NTP server because it will use less bandwidth and keep your time more accurate (by tracking your clock's drift over time and adjusting accordingly).

The ntpdate command will not run when the NTP server is running. If you run ntpdate and get a response like "the NTP socket is in use", that means your NTP server is running. Stop it with the command:

sudo /etc/init.d/ntp stop

You can now run ntpdate with the server you want to sync against as an argument. For example, to tell ntpdate to try and sync with "", run:

sudo ntpdate

When you're finished testing remember to start NTP back up again:

sudo /etc/init.d/ntp start


Fortunately NTP time syncing is pretty easy to do. Once you've set the time servers and started the NTP service up it will do its work quietly in the background.

If NTP has any problems it will log them to the system log, which you should be checking regularly anyway.

For more details on setting up an NTP server and what options are available visit the NTP documentation site. If you want to know more of the nitty-gritty about how NTP works, go to the main NTP web site and all will be revealed.

  • -- Jered

Article Comments:

DieselxXx commented Wed Dec 01 16:01:17 UTC 2010:

for rus users howto config ntp and install ntp server

Victor commented Wed Nov 07 22:45:41 UTC 2012:

Thanks for this tutorial. It helped me with my cluster

Eko Prasetyo commented Sun Mar 10 14:59:56 UTC 2013:

thanks for the article, it help me much to configure my lusca proxy server.

Aaron commented Thu May 16 23:23:23 UTC 2013:

Extremely well written article! Concise and clear to understand, and very helpful to everyone from setting up a simple time sync on their laptop to a cluster administrator. You deserve the number 1 Google rank!

Schorschi commented Wed Jul 10 19:48:39 UTC 2013:

On debian Wheezy... It appears NTP is broken? Can't get any servers listed with ntpq -p but the time server its self and it always shows INIT status hours later as the only peer.

Schorschi commented Wed Jul 10 19:49:27 UTC 2013:

On debian Wheezy... It appears NTP is broken? Can't get any servers listed with ntpq -p but the time server its self and it always shows INIT status hours later as the only peer.

Schorschi commented Wed Jul 10 20:37:01 UTC 2013:

Found the issue... # aptitude install ntp fails, but without error or warning. Where as apt-get install ntp works as expected. The issue does not present its-self until you query NTP peers and the classic INIT status is forever reported and the only peer reported is the time server its self.

Schorschi commented Wed Jul 10 20:37:33 UTC 2013:

Found the issue... # aptitude install ntp fails, but without error or warning. Where as apt-get install ntp works as expected. The issue does not present its-self until you query NTP peers and the classic INIT status is forever reported and the only peer reported is the time server its self.

Want to comment?

(not made public)


(use plain text or Markdown syntax)