SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
Network New Added 8 September 2026

chrony/NTP: clock not synchronised (Leap status: Not synchronised)

The host's clock is free running because it cannot reach a time source or has rejected the ones it has. Skew breaks far more than logs: TLS certificate validity, Kerberos tickets, JWT nbf checks and TOTP codes all fail once the drift exceeds their tolerance.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix
chronyc tracking
chronyc sources -v
timedatectl status

# UDP 123 outbound is often the blocker in cloud and corporate networks
sudo tcpdump -ni any port 123

# Cloud providers offer a link local time source that needs no egress
# AWS 169.254.169.123, Azure PTP, GCP metadata.google.internal
server 169.254.169.123 prefer iburst

sudo systemctl restart chronyd
chronyc makestep      # step the clock once, rather than slewing for hours

How to diagnose Network errors

Network errors are precise if you read them literally. Connection refused means a machine answered and actively rejected: nothing is listening on that port. Timeout means nothing answered at all, which points at a firewall silently dropping packets or a wrong address. Connection reset means the peer accepted then abruptly closed, often a proxy, a protocol mismatch, or an application crash. Distinguishing those three saves most of the debugging time.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

  1. Test layer by layer: ping for reachability, nc -zv host port for the port, then the application protocol. Do not skip to the application layer.
  2. Confirm what is listening locally with ss -tulpn. "Connection refused" on localhost almost always means the service bound to 127.0.0.1 when it needed 0.0.0.0, or vice versa.
  3. Capture packets when the error is ambiguous: sudo tcpdump -ni any port 443 and host x.x.x.x. A RST is visible; a silent drop is visible as unanswered SYNs.
  4. For intermittent failures under load, check ephemeral port exhaustion and conntrack table limits (ss -s, conntrack -S) before blaming the network.
  5. Suspect MTU when small requests succeed and large ones hang. Test with ping -M do -s 1472 and reduce until packets pass.

Tools worth reaching for

  • ss -tulpn
  • nc -zv
  • tcpdump
  • mtr
  • curl --connect-timeout
  • iptables -L -n -v

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

chrony-project.org

Related Network errors

See all 35 Network errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.