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
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 ntpInstalling 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 iburstA 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 iburstDistribution 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 iburstReachability 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.confPreserve 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 iburstApply Configuration Changes
A reload asks the running daemon to read its configuration again without fully stopping the service:
sudo service ntp reloadUse 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 restartReloading 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 ntpLook for an active running service and messages indicating configuration or startup errors. Review the service journal when synchronization does not occur:
sudo journalctl -u ntpAfter 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 -pA 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.9The 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
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 iburstReload 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.confis the main configuration file for the traditionalntpddaemon.serveridentifies an individual upstream source;pooldiscovers multiple possible sources through a pool hostname.ntpq -pdisplays 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.