Time Synchronization Collapse Due to chrony/NTP Configuration Errors 'Server OS Talk ⑩'
In server operations, the most "unassuming but fatal" issue is the collapse of time synchronization.
Application logs not lining up, DB replication failing,
certificate or token authentication failing—.
The cause being a chrony/NTP configuration error is something that happens very often in the field.
Time is the standard for infrastructure.
If this is not aligned, everything in the layers above will collapse.
Summary in a nutshell
NTP/chrony configuration errors are the type of accident that "breaks things silently."
When the time between servers drifts, everything from failure analysis and authentication to replication goes haywire.
Symptoms (Common occurrences)
Log times vary from server to server
Monitoring alerts do not match OS logs
"clock skew" errors in DB replication
Failures in TLS certificate or JWT token expiration checks
Mysterious glitches only in application session handling
chronyc sources full of "? UNREACH"
Time not synchronized between host and VM in virtual environments
Causes and Mechanisms (Why does it happen?)
Both chrony and ntpd are installed and conflicting
Misuse of "server" and "pool" directives
Incorrect IP/hostname for the upstream NTP server
UDP/123 is blocked by the firewall
In virtual environments, the host and guest are correcting each other's time causing continuous drift
RTC (hardware clock) is not unified to either UTC or JST
cloud-init overwriting other NTP settings
Figure: NTP unreachable → Server arbitrarily advances or delays time
[上位NTP] ×（到達不可）
│
▼
[サーバ] ← 自己判断で時刻調整 → ログがズレる・認証失敗
Troubleshooting (Shortest path)
-
Check the service in use (chrony or ntpd)
systemctl status chronyd systemctl status ntpd
-
Check synchronization status
chronyc tracking chronyc sources -v
-
Check connectivity to upstream NTP
nc -uvz <NTP_SERVER> 123
-
Check current time
date
If in a virtual environment, check the host's time source
Be careful of duplicate 'time synchronization' in VMware/Hyper-V/KVM.
Immediate fix (Template)
◆ Configure chrony correctly (RHEL example)
/etc/chrony.conf
server ntp.example.com iburst
# または
pool 0.jp.pool.ntp.org iburst
-
Service restart
systemctl restart chronyd
-
Immediate synchronization (forced)
chronyc makestep
-
Disable conflicting ntpd
systemctl disable --now ntpd
◆ Open UDP/123 in the firewall
NTP must use UDP/123. It is very common for this to be closed.
◆ Disable 'double synchronization' in virtual environments
Disable time synchronization in VM Tools
Or disable chrony and unify with the host (choose one or the other)
Permanent countermeasures / Recurrence prevention checklist
Standardize on 'which one to use' between chrony and ntpd
Unify upstream NTP servers within the company
Ensure communication path for UDP/123
Prevent cloud-init from overwriting NTP settings
Clarify host/guest synchronization method in virtual environments
Incorporate 'chronyc tracking' into monitoring
Unify RTC (hardware clock) to UTC
Regularly inspect the load and availability of the NTP server side
Pitfalls (common mistakes)
Mixing 'server' and 'pool' in chrony.conf
Firewall blocking pool.ntp.org
Configured multiple NTP servers, but one is stuck due to an incorrect IP
chrony.conf is ignored because settings are overwritten by cloud-init
In a virtual environment, the host and VM are 'pushing' time against each other, causing continuous drift
Checkpoints after changes
chronyc sources shows a synchronized state with ^*
Offset (drift) is stable within a few to several tens of milliseconds
Log time matches the actual time
Consistent with the occurrence time of monitoring alerts
The synchronization method between the VM and host is consistent
Summary (Action Guidelines)
Time synchronization is the 'baseline of infrastructure'.
If this is off, logs, authentication, and replication will all collapse.
Standardize on chrony/ntpd → Configure upstream NTP correctly → Monitor synchronization status.
This alone can almost entirely prevent the collapse of time synchronization.