Linux server time not in sync with ntp server

July 07, 2026 — LiveStream

Feeling frustrated because your Linux server time isn't syncing with the NTP server? You're not alone, it’s a common yet critical issue that can bring down entire services, especially when dealing with authentication protocols like Kerberos or ensuring data integrity in databases. This guide will help you understand, diagnose, and fix your Linux server time not in sync with NTP server problems, ensuring your systems are precisely synchronized.

It’s happened to the best of us, right? You log into a server, run a date command, and arre yaar, the time is off by a few minutes, or worse, hours! In the past, a few minutes here or there might have been "chalta hai" – no big deal. But in today’s interconnected world, where every millisecond counts, an unsynchronized Linux server can lead to a world of pain. We're talking authentication failures, corrupt database entries, messed-up logs, and security nightmares. So, let’s grab a cup of chai and dive deep into understanding why accurate time is paramount, how Linux systems manage time, and most importantly, how to troubleshoot and fix those pesky Linux server time not in sync with ntp server issues.

The Unseen Pillar: Why Accurate Time Synchronization Matters So Much

Imagine a grand symphony orchestra. If each musician decides to play at their own pace, the result is chaos, not music. Similarly, in a distributed system, if servers aren’t synchronized, the entire "symphony" of operations can fall apart. This isn't just about showing the correct time on your terminal; it's fundamental to system integrity, security, and functionality.

The most prominent example of where even a slight time skew causes massive headaches is with authentication protocols like Kerberos. Kerberos, widely used in corporate environments, relies heavily on precise time synchronization between clients, servers, and Key Distribution Centers (KDCs). It implements a built-in protection against "replay attacks" by issuing tickets with a limited valid lifetime. If your client's time is significantly different from the KDC's time (usually more than 5 minutes), your authentication requests will be rejected. The system, in its wisdom, assumes you might be an attacker trying to reuse an old ticket or generate a future one. So, even if you’re a perfectly legitimate user, your access will be denied. "Access Denied" just because your clock is off? Pakka, it happens!

Beyond authentication, consider the ripple effect on other critical areas:

• Database Consistency: In database systems, especially those with replication or distributed transactions, timestamp accuracy is crucial. If servers in a cluster have different times, the order of transactions can get confused, leading to data inconsistency, replication conflicts, or even data loss. Imagine a scenario where a transaction committed at "5:00 PM" on one server appears to be committed at "4:55 PM" on another, breaking the chronological order of operations. This can be a real headache to untangle.
• Log Files and Forensics: Log files are the bread and butter of troubleshooting, auditing, and security forensics. If your server clocks are out of sync, reconstructing the sequence of events during a security incident or debugging a complex application issue becomes incredibly difficult, if not impossible. "Did event A happen before event B, or was it the other way around?" becomes an unanswerable question when timestamps are unreliable. This can severely hamper your ability to identify root causes or comply with auditing requirements.
• Application Behavior: Many applications, especially those dealing with financial transactions, scheduled tasks, or real-time data processing, rely on accurate time. A time jump or lag can cause scheduled jobs to run at the wrong time, data to be processed incorrectly, or complex distributed applications to malfunction.
• Cryptographic Operations: Beyond Kerberos, many other cryptographic processes and digital certificate validations depend on accurate time. An incorrect system time can lead to certificate expiration issues or failed secure communication.

Historically, systems relied on a Real-Time Clock (RTC), a hardware component with a battery-backed crystal oscillator, to keep time. While useful for maintaining time when the system is powered off, RTCs are prone to drift. No crystal is perfect, and over time, the RTC clock can run slightly fast or slow, accumulating errors. This means your system could gradually start living in the future or the past, according to its internal clock.

The solution to this drift came with advancements like atomic clocks, which use the resonant frequencies of atoms to achieve incredible precision. Then came the Network Time Protocol (NTP), a mechanism designed to share this precision across networks. NTP allows our systems to synchronize their clocks with highly accurate time sources, often traceable back to these atomic clocks. This ensures that all connected devices agree on the current time, making the interconnected world functional.

Linux Timekeeping Demystified: Options and Mechanisms

Linux, being the versatile beast it is, offers several ways to manage and synchronize its system time. Understanding these options is key to diagnosing and fixing synchronization issues. Let's break them down.

No Synchronization - The Risky Default (Sometimes Necessary)

The "no synchronization" option means there's no active software process on your Linux system trying to connect to external time sources to adjust its clock. While this sounds like a guaranteed path to time drift, it's not always the case, especially in virtualized environments.

In virtual machines (VMs), the guest operating system (your Linux server) might rely on the host system for its time. When a VM starts, it typically inherits the host's time. During its uptime, virtualization tools (like VMware Tools for VMware, qemu-ga for KVM, or XenTools for Xen) can periodically communicate with the host to keep the guest time somewhat aligned.

However, this method has its pitfalls. If the VM host itself isn't properly synchronized, all its guests will inherit incorrect time. Moreover, VMs are susceptible to "time skewing" – gradually drifting out of sync – especially if the guest isn't accurately counting CPU cycles. Factors like CPU speed adjustments, pauses in VM execution (e.g., during host resource contention or snapshots), or inaccurate clock source emulation can cause significant drift. This is why even in virtualized environments, running an NTP daemon within the guest is often recommended as a fallback or primary method for robust synchronization.

The Daemons: ntpd and chrony - Continuous Guardians

For reliable, continuous time synchronization, Linux systems typically employ a dedicated daemon (a background process) that constantly monitors and adjusts the system clock. The two most common players here are ntpd and chronyd.

ntpd - The Veteran Timekeeper

The ntpd (Network Time Protocol daemon) is the classic choice for NTP synchronization on Linux. It's a robust process that continuously compares your system's clock with multiple configured NTP servers. Here's how it generally works:

1. Polling: ntpd periodically polls configured NTP servers (peers) to request their current time.
2. Stratum Levels: NTP servers are organized into "strata" based on their proximity to a primary time source (like an atomic clock). Stratum 0 are atomic clocks, Stratum 1 are servers directly connected to Stratum 0, Stratum 2 are servers getting time from Stratum 1, and so on. ntpd prefers lower stratum servers, as they are considered more accurate.
3. Peer Selection & Algorithms: ntpd uses sophisticated algorithms (like the "Marzullo's algorithm") to analyze responses from multiple NTP servers. It identifies "good" servers, filters out "false-tickers" (servers providing incorrect time), and calculates the most accurate time.
4. Slewing vs. Stepping: Once ntpd determines the true time, it adjusts your system clock.
   • Slewing: For small time differences (typically less than 0.5 seconds), ntpd "slews" the clock. This means it slightly speeds up or slows down the system clock until it matches the correct time. This adjustment is gradual and doesn't cause sudden jumps, preventing applications from getting confused.
   • Stepping: For larger time differences, ntpd might "step" the clock, meaning it immediately jumps the system time forward or backward. This can be disruptive to applications and is usually avoided unless the initial time difference is too large. By default, ntpd will step at boot if the time difference is significant, but during normal operation, it prefers slewing.
5. Hardware Clock Sync: ntpd typically also synchronizes the hardware clock (RTC) with the system clock, ensuring both have the same understanding of time.

Configuration (/etc/ntp.conf): A basic ntp.conf might look like this:

# Use public servers from the ntp.org pool
server 0.centos.pool.ntp.org iburst
server 1.centos.pool.ntp.org iburst
server 2.centos.pool.ntp.org iburst
server 3.centos.pool.ntp.org iburst

# Drift file to store clock frequency adjustments
driftfile /var/lib/ntp/ntp.drift

# Allow only query access to this host
restrict default nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict ::1

chrony - The Modern, Agile Timekeeper

chrony is a newer, increasingly popular alternative to ntpd. It's designed to perform well under conditions that ntpd struggles with, making it particularly suitable for:

• Intermittently Connected Systems: Laptops or VMs that are frequently suspended or disconnected from the network.
• Systems with Unstable Clocks: VMs or hardware with poor RTCs.
• Faster Synchronization: chrony can synchronize the clock much faster and with greater accuracy, especially after a period of disconnection or a large time offset.
• Better Resource Utilization: It's generally more resource-efficient than ntpd.

chrony also uses sophisticated algorithms to determine accurate time, and it primarily "slews" the clock to avoid sudden jumps. Its fast synchronization capabilities are a major advantage in dynamic cloud environments or for VMs that might experience frequent pauses.

Configuration (/etc/chrony.conf): A typical chrony.conf would look something like this:

# Use public servers from the ntp.org pool
pool 0.centos.pool.ntp.org iburst
pool 1.centos.pool.ntp.org iburst
pool 2.centos.pool.ntp.org iburst
pool 3.centos.pool.ntp.org iburst

# This directive enables kernel synchronisation (enabled by default)
# makestep 1.0 -1
# rtcdevice /dev/rtc0

# Drift file
driftfile /var/lib/chrony/chrony.drift

# Allow NTP client access from local network
# allow 192.168.0.0/16

# This enables the NTPD compatible client for the KVM virtio-time source.
# This should be enabled in virtual machines where the host also runs chronyd.
# Alternatively use 'source /dev/virtio-ports/org.qemu.guest_agent.0' if running qemu-ga.
# rtcsync

Note the rtcsync option that keeps the hardware clock in sync, and makestep for handling large initial time discrepancies.

The Clients: ntpdate - One-Shot Syncs

Tools like ntpdate or rdate are simpler NTP clients. They perform a one-time query to an NTP server and, if successful, immediately adjust the system clock. They do not run as a continuous daemon.

While ntpdate might seem convenient, especially for initial synchronization or scripting, it has significant drawbacks:

• Stepping, Not Slewing: ntpdate performs a "step" adjustment, meaning it instantly jumps the clock. As discussed, this can confuse applications and cause issues.
• No Continuous Monitoring: It doesn't continuously monitor or correct time drift, making it unsuitable for maintaining accurate time over extended periods.
• Deprecated: On most modern Linux distributions, ntpdate is considered deprecated in favor of ntpd or chronyd, especially with systemd-timesyncd providing basic daemon functionality.

You might use ntpdate in a script during initial setup to get a rough time, before starting a full-fledged NTP daemon. For example: sudo ntpdate -s 0.centos.pool.ntp.org. But for ongoing operations, stick to the daemons.

Virtualization Tools - Host-Client Harmony

As mentioned under "No Synchronization," specialized tools in virtualized environments play a role. VMware Tools, KVM's virtio-time, and XenTools are client utilities installed within a guest VM. They perform various system housekeeping tasks, including enhancing time synchronization between the guest and the host.

These tools can help mitigate drift by providing periodic time synchronization from the host. However, they are often considered a complementary mechanism rather than a primary time source. For mission-critical VMs, combining these tools with an in-guest NTP daemon (like chronyd for its VM-friendly features) offers the most robust timekeeping.

Troubleshooting "Linux server time not in sync with ntp server" - Practical Steps (Hinglish touch)

Okay, so your Linux server time not in sync with ntp server hai. Let’s roll up our sleeves and fix it. We’ll go through a structured approach, starting with basic checks and moving to more in-depth diagnostics.

Initial Checks & Common Culprits

Before diving deep into NTP daemon logs, let's cover the simple stuff. Many issues are caused by basic misconfigurations or network problems.

1. Check Current Time & Status: The timedatectl command is your best friend on systemd-based systems (which is most modern Linux distributions).

timedatectl

Look for:

• Local time:: Your current system time.
• Universal time:: UTC time.
• RTC time:: Hardware clock time.
• NTP service:: Should be active.
• System clock synchronized:: Should be yes.
• NTP synchronized:: Should be yes.
• If NTP service is inactive or System clock synchronized is no, it’s a clear indication something is wrong with your NTP setup.

2. Verify NTP Service Status: Is your NTP daemon (either ntpd or chronyd) actually running?

For ntpd:

sudo systemctl status ntpd

For chronyd:

sudo systemctl status chronyd

If the service isn't running, start it and enable it to start on boot:

sudo systemctl start ntpd   # or chronyd
sudo systemctl enable ntpd  # or chronyd

If it fails to start, check journalctl -xe for error messages.

3. Firewall Check: NTP uses UDP port 123. Is your firewall blocking outgoing (and potentially incoming, if it's an NTP server) NTP traffic?

For firewalld (CentOS/RHEL, Fedora):

sudo firewall-cmd --add-service=ntp --permanent
sudo firewall-cmd --reload

For ufw (Ubuntu/Debian):

sudo ufw allow ntp
sudo ufw reload

If you have specific iptables rules, you’ll need to adjust those manually. Pakka check this one; it's a very common culprit!

4. NTP Server Reachability: Can your server even reach the configured NTP servers? You can try pinging one of them (though NTP uses UDP, ping uses ICMP, so it's not foolproof, but gives a hint):

ping 0.pool.ntp.org

A better way is to check port 123 connectivity:

nmap -p 123 0.pool.ntp.org # Install nmap if not present

It should show port 123 as open or filtered (meaning it’s reachable but might have a firewall in between). If it shows closed or host unreachable, you have a network connectivity issue.

Diagnosing with ntpd

If ntpd is running, but your time isn't syncing, the ntpq utility is your best friend.

1. Check Peer Status (ntpq -p):

ntpq -p

This command lists the NTP servers your ntpd is configured to poll and their current status.

Output Explanation:

• remote: The NTP server's hostname or IP.
• refid: The reference ID (usually the stratum of its own time source).
• st: Stratum level. Lower is better (1 is primary, 2 is secondary, etc.).
• t: Type (local, unicast, broadcast, etc.).
• when: How many seconds ago the last packet was received.
• poll: The polling interval in seconds.
• reach: An octal shift register value (0-377) indicating the success of the last eight polls. 377 means all 8 polls were successful. Any other value indicates dropped packets.
• delay: Network round-trip delay to the server.
• offset: The estimated time difference between your system clock and the remote server's clock (in milliseconds). This is what ntpd tries to minimize. If this value is consistently high (e.g., hundreds or thousands of milliseconds), you have a sync problem.
• jitter: A measure of the variability of the offset.

Symbols in front of remote:

• *: The system's currently selected peer (the one ntpd is actively syncing with).
• +: A good candidate for synchronization, but not currently selected.
• -: A candidate that has been rejected (e.g., inconsistent time, false-ticker).
• x: A false-ticker that has been discarded.
• #: Peer selected for synchronization, but currently undergoing initial setup.
• o: PPS (Pulse Per Second) peer.
• (space): Not currently a suitable candidate.

If you see no servers or all servers marked with - or x, ntpd isn't happy with any of its sources. This could be due to firewall issues, network reachability, or the NTP servers themselves being unreliable.

2. Review ntp.conf: Double-check your /etc/ntp.conf file.

• Are the server lines correct? Are they reliable public NTP servers or your internal NTP servers?
• Are there any restrict directives that might be inadvertently blocking communication?
• Tip: Using iburst (e.g., server 0.pool.ntp.org iburst) causes ntpd to send a burst of packets at startup to quickly synchronize, which is generally good.

3. One-shot Sync with ntpd -gq (Caution!): You can try to force a one-time step adjustment with ntpd -gq.

sudo systemctl stop ntpd
sudo ntpdate -q 0.pool.ntp.org # This is more gentle if you just want to see the offset
sudo ntpd -gq # This steps the time, can be disruptive!
sudo systemctl start ntpd

The -g option allows ntpd to make a large time jump (step) if necessary, and -q means it will exit after setting the time. Only use -gq when you understand the implications of a sudden time jump on your applications. It's usually best for initial setup or after a long outage.

Diagnosing with chrony (The Modern Way)

If you're using chrony, you have a different set of commands for diagnostics.

1. Check Source Status (chronyc sources):

chronyc sources

This command displays information about the NTP sources chronyd is currently using or attempting to use.

Output Explanation:

• Source Name: The NTP server.
• State: ^ for server, = for peer.
• Stratum (St): Stratum level.
• Time since last sync (LastRx): How long ago the last successful measurement was received.
• Offset: Estimated difference between your clock and the source's clock (in seconds). This is what chronyd tries to minimize.
• R.MSE: Root Mean Square Error.
• Freq: Estimated frequency error.
• Skew: Estimated maximum error.
• ~ (tilde): Indicates the source is a good candidate for synchronization.
• ?: Indicates the source is currently unreachable.

If you see sources with ? or consistently high offsets, you know where to focus your attention.

2. Check Tracking Status (chronyc tracking):

chronyc tracking

This command provides detailed information about chrony's current state of synchronization, including the reference ID, stratum, offset, and the last time a clock update occurred. Look for Reference ID, Stratum, Last offset, and RMS offset. If Reference ID is (none) or Stratum is 0, it's not synchronized.

3. Review chrony.conf: Check your /etc/chrony.conf file.

• Are the pool or server directives correct?
• Are there any allow or deny rules blocking access?
• Ensure rtcsync is enabled if you want to keep the hardware clock in sync.

Dealing with False-Tickers and Other Anomalies

Sometimes, the issue isn't your configuration or firewall, but the NTP servers themselves. A "false-ticker" is an NTP server that provides incorrect time. Robust NTP daemons like ntpd and chronyd are designed to detect and disregard these servers using various statistical methods and voting algorithms.

• Choose Reliable Servers: Always use reliable NTP sources. Public NTP Pool Project servers (e.g., 0.pool.ntp.org, 1.pool.ntp.org) are generally good, but for production environments, consider using regional pools (e.g., in.pool.ntp.org for India) or dedicated corporate NTP servers that are properly maintained.
• Multiple Sources: Always configure at least three, ideally four or more, diverse NTP servers. This redundancy helps the daemon filter out outliers and ensures continued synchronization even if one server goes down.

Manual Time Adjustment (Last Resort)

In emergency situations or for non-production systems where an immediate, crude time correction is needed, you can manually set the time. Use this with extreme caution as it causes a severe time jump and can wreak havoc on running applications and database transactions.

1. Set System Date and Time:

sudo date -s "YYYY-MM-DD HH:MM:SS"

Example: sudo date -s "2023-10-27 10:30:00"

2. Sync System Time to Hardware Clock: If your system date is correct, you might want to push it to the hardware clock (RTC) so it persists across reboots.

sudo hwclock --systohc

After a manual adjustment, it's crucial to restart your NTP daemon and monitor its status to ensure it can gracefully take over and maintain the corrected time.

Best Practices for Robust NTP Synchronization

Achieving and maintaining accurate time synchronization is an ongoing process, not a one-time fix. Here are some best practices to keep your Linux servers happily synchronized:

1. Choose Your NTP Sources Wisely:

• Public NTP Pools: For most general-purpose servers, pool.ntp.org or regional pools (e.g., in.pool.ntp.org) are good starting points.
• Internal NTP Servers: In enterprise environments, it's best practice to set up your own internal Stratum 2 NTP servers that synchronize with public Stratum 1 or 2 sources. This reduces external network dependencies and provides better control.
• Diversify: Don't rely on just one or two servers. Configure at least 4-5 diverse sources to provide redundancy and allow your daemon to perform accurate peer selection.

2. Secure Your NTP Daemon: NTP can be susceptible to amplification attacks if not properly secured.

• ntpd Restrictions: In ntp.conf, use restrict directives to limit access. A common approach is to allow only local host queries and block everything else by default:

restrict default nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict ::1

• chronyd Access Control: Similar allow and deny directives exist in chrony.conf.
• Firewall: Always restrict UDP port 123 access to only necessary clients and your chosen NTP servers.

3. Monitor NTP Status Continuously: Don't just set it and forget it! Integrate NTP status monitoring into your existing monitoring solutions (e.g., Prometheus, Zabbix, Nagios).

• Monitor the synchronization status (timedatectl), offset (ntpq -p or chronyc tracking), and reachability of your NTP servers.
• Set up alerts if a server loses sync, if the offset becomes too large, or if the NTP daemon itself isn't running. This proactive approach saves you from unpleasant surprises.

4. Consider chrony for Modern Deployments: For most new Linux server deployments, especially in virtualized or cloud environments, chrony is often the preferred choice over ntpd due to its faster sync times, better performance with intermittent connectivity, and superior handling of clock instabilities.

5. Regularly Review Configurations: Periodically review your ntp.conf or chrony.conf files. Are the NTP servers still valid and reliable? Have there been any network changes that might affect connectivity?

By following these best practices, you can ensure your Linux servers maintain accurate time, preventing a whole host of potential issues and ensuring the smooth operation of your applications and services. Yeh sab time synchronization, ekdum zaroori hai, boss!

Key Takeaways

• Accurate time synchronization is critical for security (Kerberos), data integrity (databases, logs), and distributed system functionality.
• Hardware RTCs are prone to drift; NTP provides precise synchronization with external time sources.
• Linux offers daemons (ntpd, chronyd) for continuous synchronization, clients (ntpdate) for one-off adjustments, and virtualization tools for host-guest sync.
• chrony is generally recommended over ntpd for modern, especially virtualized, environments due to its agility and faster sync capabilities.
• Troubleshooting involves checking service status, firewall rules, NTP server reachability, and using tools like timedatectl, ntpq -p, and chronyc sources.
• Always configure multiple, reliable NTP sources and secure your NTP daemon.
• Continuous monitoring of NTP status is crucial for proactive issue detection.
• Manual time adjustment (date -s) should be a last resort due to its disruptive nature.

Frequently Asked Questions

Why is my Linux server time drifting even with NTP configured?

Time drift with NTP configured can stem from several issues: firewall blocking UDP port 123, unreachable or unreliable NTP servers, incorrect ntp.conf or chrony.conf settings (e.g., no server/pool lines), the NTP daemon not running, or even underlying hardware clock instability (especially in VMs or older hardware). Use ntpq -p or chronyc sources to diagnose if the daemon is successfully communicating with its sources.

What's the difference between ntpd and chronyd?

ntpd is the traditional NTP daemon, robust but can be slower to synchronize, especially after long disconnections or for systems with unstable clocks. chronyd is a newer implementation, designed for faster synchronization, better performance in virtualized environments, and more robust handling of intermittent network connectivity and clock instability, making it often the preferred choice for modern deployments.

How do I configure NTP on a fresh Linux install?

On modern systemd-based Linux distributions, systemd-timesyncd often provides basic NTP client functionality. For full-fledged daemon-based synchronization, install either ntp (for ntpd) or chrony (for chronyd).

1. Install: sudo yum install chrony (RHEL/CentOS) or sudo apt install chrony (Debian/Ubuntu).
2. Configure: Edit /etc/chrony.conf (or /etc/ntp.conf) to specify pool or server directives, usually pointing to pool.ntp.org or your internal NTP servers.
3. Start & Enable: sudo systemctl start chronyd (or ntpd) and sudo systemctl enable chronyd.
4. Verify: Use timedatectl, chronyc sources, or ntpq -p.

Can I use ntpdate for continuous synchronization?

No, ntpdate is designed for one-time, immediate clock adjustments (a "step"). It does not run as a continuous background process to monitor and gradually adjust time. Using ntpdate regularly via cron can cause abrupt time jumps that are disruptive to applications. For continuous and graceful time synchronization, always use a dedicated NTP daemon like ntpd or chronyd.

Got more time sync issues or curious to see these commands in action? Head over to the @explorenystream YouTube channel for more insightful DevOps content and subscribe to stay updated!