Time sync on a VPS — chrony, systemd-timesyncd, why time matters

Wrong clocks break things in ways that are infuriating to debug: TLS handshakes fail with "certificate not yet valid," log timestamps lie about when events happened, replication drifts, two-factor auth tokens stop validating, and PBX call records get assigned to the wrong day. The VPS hypervisor usually presents a reasonable clock at boot, but the guest still needs to keep itself in sync over time. This article covers the two real options and what to pick.

The two contenders

chrony — modern NTP daemon, fast convergence, good behavior under variable latency. Default on AlmaLinux. Worth installing on Debian/Ubuntu too if you care about precision.

systemd-timesyncd — lightweight SNTP client built into systemd. Default on Debian and Ubuntu. Adequate for most VPSes; doesn't do the corrections-with-history that chrony does.

Pragmatic recommendation:

• General-purpose VPS (web, mail, app server): systemd-timesyncd is fine. Default behavior on Debian/Ubuntu.
• Database server, especially with replication: chrony — replication relies on consistent timestamps, drift causes hard-to-diagnose bugs.
• PBX VPS: chrony — call records, SIP timestamps, and DAHDI-style hardware all expect accurate time. ViciBox® ships with chrony pre-configured.
• Anything dealing with TLS in unusual ways (certificate authorities, OCSP responders): chrony.

Installing and configuring chrony

# Debian / Ubuntu (disables systemd-timesyncd; both can't run at once)
apt install chrony

# AlmaLinux (already installed by default)
dnf install chrony

Default config at /etc/chrony/chrony.conf (Debian) or /etc/chrony.conf (Alma) uses the distro's NTP pool — fine for most cases. To use specific pools (Google, Cloudflare, or your own internal NTP):

# Use Cloudflare's NTP service
server time.cloudflare.com iburst nts
# OR use the NTP pool project (default)
pool 2.debian.pool.ntp.org iburst

Activate:

systemctl enable --now chronyd       # 'chrony' on Debian, 'chronyd' on Alma
chronyc tracking                     # show current sync state
chronyc sources                      # show which servers you're talking to

Within a minute of starting, chronyc tracking should show "Leap status: Normal" and a "System time" offset of milliseconds, not seconds.

systemd-timesyncd — the lightweight option

On Debian/Ubuntu it's the default. To verify it's running:

systemctl status systemd-timesyncd
timedatectl status                   # human-readable summary

To customize the NTP server, edit /etc/systemd/timesyncd.conf:

[Time]
NTP=time.cloudflare.com
FallbackNTP=pool.ntp.org

Then systemctl restart systemd-timesyncd.

Verifying time is right

date                                 # local time
date -u                              # UTC
timedatectl                          # systemd's status
chronyc tracking                     # chrony's view
ntpdate -q pool.ntp.org              # one-shot query without changing anything

If chronyc tracking shows the System time offset growing over hours, something's wrong — usually a firewall blocking outbound UDP 123 (default NTP port). LYLIX VPSes have unrestricted outbound by default, but check your in-VPS firewall.

Timezone

Storing time in UTC and converting on display is the right default. Set the system timezone with:

timedatectl set-timezone America/New_York

The hardware clock should stay in UTC (timedatectl set-local-rtc 0) — only desktops with Windows dual-boot need local RTC. On a VPS, always UTC.

The hardware-clock thing on virtual machines

Virtualized VPSes get their time from the hypervisor at boot. On VM-based plans, qemu-guest-agent or a paravirtual clock source keeps the guest from drifting against the host. You don't need to mess with this; chrony or timesyncd handles it transparently. The relevant kernel module is kvm_clock on KVM-virtualized VPSes — check cat /sys/devices/system/clocksource/clocksource0/current_clocksource to confirm.