Configure an NTP Client on Linux

Install and configure the traditional NTP client on Ubuntu or Debian, select time sources, restart ntpd, verify peers, and troubleshoot synchronization problems.

What NTP Does

NTP, or Network Time Protocol, synchronizes a computer's local clock with time provided by remote network sources. An NTP client requests time from one or more upstream sources. An NTP server provides time information to other clients. A single Linux machine can perform either role, but this lesson configures it as a client.

Accurate time is important because timestamps are used in system logs, scheduled jobs, certificate validation, authentication systems, distributed applications, and incident troubleshooting. Even a small clock difference can make events appear out of order or cause security checks to fail.

NTP Client Configuration Workflow

StepActionFile or CommandExpected Result

1 — Install the daemon — sudo apt-get install ntp — The ntp package and traditional ntpd service are available.

2 — Review sources — /etc/ntp.conf — Valid pool or server directives identify upstream sources.

3 — Apply changes — sudo service ntp reload or sudo service ntp restart — The daemon uses the current configuration.

4 — Check the service — sudo systemctl status ntp — The service is running without configuration errors.

5 — Check peers — ntpq -p — Reachable peers and the selected synchronization source are visible.

Prerequisites

  • Basic Linux command-line navigation.
  • Permission to use sudo.
  • Basic APT package-management skills.
  • Access to a terminal text editor such as nano.
  • Basic knowledge of Linux services, DNS, and network connectivity.

Install the Traditional NTP Daemon

On Ubuntu and Debian systems, the traditional NTP implementation is commonly provided by the ntp package. Its background service is called ntpd. Install it with administrative privileges:

sudo apt-get install ntp

Installing the package normally creates the main configuration file at /etc/ntp.conf and enables the ntp service. Before or after installation, check whether another time service is active. Select one client implementation rather than allowing multiple services to control the clock.

Understand /etc/ntp.conf

/etc/ntp.conf is the primary configuration file for the traditional ntpd service. Among its settings, server and pool directives define where the client obtains time.

A server directive names one individual upstream NTP server:

server ntp1.example.internal iburst

A pool directive names a pool hostname. DNS can return different members of the pool, allowing the client to use multiple possible servers and improving availability:

pool 0.ubuntu.pool.ntp.org iburst
pool 1.ubuntu.pool.ntp.org iburst
pool 2.ubuntu.pool.ntp.org iburst
pool 3.ubuntu.pool.ntp.org iburst

Distribution defaults may already contain regional or vendor-maintained pool names. A pool does not represent just one fixed machine; it provides a way to discover several suitable time servers.

Select Appropriate Time Sources

Keep the distribution's default pool entries when they meet your network and organizational requirements. Replace or supplement them when your organization requires approved internal servers, a regional source, or a particular public NTP service.

Use multiple independent sources when possible. Multiple sources help the daemon compare responses and continue operating if one source becomes unavailable. On a private or isolated network, direct access to public pools may be prohibited or impossible. In that case, configure the organization's internal NTP servers:

server ntp1.example.internal iburst
server ntp2.example.internal iburst

Reachability requires more than a valid-looking hostname. The client needs:

  • Successful DNS resolution for the configured hostname.
  • A route to the remote network.
  • Firewall rules that allow NTP traffic.
  • Outbound, and where applicable return, traffic over UDP port 123.

Do not remove valid default sources unless you are replacing them with approved alternatives. A configuration with no usable upstream source cannot synchronize.

Edit the Configuration

Open the file with a text editor:

sudo nano /etc/ntp.conf

Preserve valid syntax. Each server or pool directive should contain a valid hostname or address, optionally followed by supported options such as iburst. Avoid deleting required defaults without adding replacement sources. Save the file after making changes.

For a simple client configuration, the important part might look like this:

pool 0.ubuntu.pool.ntp.org iburst
pool 1.ubuntu.pool.ntp.org iburst
pool 2.ubuntu.pool.ntp.org iburst
pool 3.ubuntu.pool.ntp.org iburst

Apply Configuration Changes

A reload asks the running daemon to read its configuration again without fully stopping the service:

sudo service ntp reload

Use a restart when a reload is insufficient, when the daemon needs to be reinitialized, or when troubleshooting a service that did not apply changes:

sudo service ntp restart

Reloading usually causes less disruption. Restarting stops and starts the daemon, so it is a stronger action and may briefly interrupt its time-management process.

Check Service and System Status

On systemd-based Ubuntu and Debian systems, inspect the service with:

sudo systemctl status ntp

Look for an active running service and messages indicating configuration or startup errors. Review the service journal when synchronization does not occur:

sudo journalctl -u ntp

After synchronization begins, confirm that the system clock moves toward the selected source and remains synchronized. Initial synchronization is not always immediate: the daemon may need several polls after startup or after its sources change.

Inspect Peers with ntpq -p

The ntpq utility queries the operational state of ntpd. Display configured peers with:

ntpq -p

A typical result resembles the following:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*ntp1.example     .GPS.         str  2   32   64    377    12.4    -0.8     1.2
+ntp2.example     .PPS.        str  2   28   64    377    14.1     0.4     0.9

Field or MarkerMeaningWhat a Healthy Value Looks Like

* — The peer currently selected for synchronization — One eligible source is normally marked with an asterisk.

+ — A source considered a good candidate but not currently selected — One or more additional usable sources may appear.

remote — The configured peer or pool member — A recognizable hostname or address.

refid — The reference clock identifier reported by the peer — A valid reference identifier rather than an error marker.

st or stratum — The peer's distance from a reference clock; lower values are generally closer to the reference source — A plausible stratum for the environment.

poll — The polling interval, in seconds — A changing interval managed by the daemon.

reach — Recent communication success history — A nonzero value, commonly increasing toward 377 in healthy repeated communication.

delay — Approximate network round-trip delay — A stable, reasonable value for the network path.

offset — Measured difference between the local clock and the peer — A small and generally decreasing value after synchronization.

jitter — Variation in measured timing — A stable, relatively small value.

The exact columns can vary slightly by implementation or output formatting. Focus on whether peers are reachable, whether the reachability value is nonzero, and whether an eligible source is marked with *.

Common Synchronization Problems

SymptomLikely CauseDiagnostic CheckResolution

No usable peer or no * marker — The daemon needs more polling time, sources are unavailable, DNS fails, or UDP 123 is blocked — Run sudo systemctl status ntp, ntpq -p, and review sudo journalctl -u ntp — Confirm DNS, routing, firewall rules, and source availability; wait through several polling intervals and query again.

Configured server name is invalid — A malformed hostname or address — Review the related line in /etc/ntp.conf and check service logs — Correct the name and reload or restart the service.

Peers show no reachability — Network routing or firewall rules prevent UDP port 123 traffic — Check local and network firewall policy and verify DNS resolution — Permit required NTP traffic or use an approved reachable source.

Service fails after editing — Invalid directive syntax, malformed address, or accidentally removed configuration — Run sudo systemctl status ntp and sudo journalctl -u ntp — Review recent edits, restore valid server or pool directives, then restart.

Service runs but the clock does not change — Another time service controls the clock, no peer is eligible, or the local clock has substantial drift — Identify active time services and inspect ntpq -p — Keep one primary client, correct source access, and follow local policy for large clock corrections.

Internal host cannot use public pools — External NTP traffic is intentionally blocked — Review network policy and internal time-service requirements — Configure approved internal NTP servers instead.

Changes have no effect — The file was not saved, or the daemon was not reloaded or restarted — Reopen /etc/ntp.conf and check service status — Save valid edits and apply them with reload or restart.

Large Clock Differences and Competing Services

If the local clock differs greatly from network time, correction may be delayed or handled according to the daemon's safety policy. Follow your operating procedures for making an initial manual correction when required, then allow ntpd to maintain the clock.

Also check for concurrent services. Common alternatives include systemd-timesyncd and chrony. Identify which service is intended for the machine, disable or avoid competing implementations according to distribution and organizational policy, and then restart the chosen client.

Practical Examples

Use the Distribution Defaults

Install ntp, inspect /etc/ntp.conf, and retain valid default pool entries. After applying the configuration, run ntpq -p and wait for a selected peer if synchronization is still initializing.

Use Company Time Servers

Replace or supplement public pool entries with approved internal sources:

server ntp1.example.internal iburst
server ntp2.example.internal iburst

Reload or restart the service, then verify that the internal sources appear in ntpq -p and that one eligible source receives the * marker.

Operate on an Isolated Network

Configure an internal NTP server that is reachable from the isolated host. Do not assume public pool names will work: the network may block external DNS, routing, or UDP port 123. Coordinate the required internal hostname, route, and firewall policy with the network administrators.

Exam-Relevant Notes

  • /etc/ntp.conf is the main configuration file for the traditional ntpd daemon.
  • server identifies an individual upstream source; pool discovers multiple possible sources through a pool hostname.
  • ntpq -p displays peer and synchronization information.
  • The * marker identifies the currently selected synchronization source.
  • NTP uses UDP port 123.
  • DNS resolution, routing, firewall rules, and service conflicts can all prevent synchronization.
  • After changing configuration, reload or restart the service before judging whether the change worked.

For this traditional implementation, the complete flow is: install ntp, review /etc/ntp.conf, select reachable and approved sources, apply the configuration, check the service, and verify peers with ntpq -p.