When the clock is badly wrong and you cannot wait for the next poll, toggle the NTP client off and back on — sudo timedatectl set-ntp false followed by sudo timedatectl set-ntp true — or restart systemd-timesyncd directly. Either action throws away the client's retry schedule and triggers an immediate query against its configured time servers.
Why a virtual machine clock ends up days off
A virtual machine has no battery-backed clock of its own. At boot, the guest's virtual RTC is seeded from the host clock, and after a saved-state restore or a host suspend it simply resumes from where it stopped. If the host clock was wrong at that moment — a dead CMOS battery, a dual-boot setup that stores local time instead of UTC, or the physical machine was simply powered off — the guest inherits the error. From there the guest stays wrong until its NTP client completes its first successful exchange with a time server.
That first exchange can take longer than you expect. systemd-timesyncd waits until the network is considered up, resolves the server names, and retries with an exponentially increasing back-off whenever a request fails. The "it corrected itself eventually" behaviour you noticed is normal: the client gets there, just not instantly.
Why "System clock synchronized: yes" is not proof
The synchronized flag in timedatectl status records the outcome of the last completed sync, not a live measurement. Once a sync has succeeded, the flag stays "yes" even if the clock later drifts or the server becomes unreachable. Treat it as history, not as a health check.
For a real picture, inspect the sync state and the service log:
timedatectl show-timesync
journalctl -u systemd-timesyncd --no-pager -n 30The journal shows which server was contacted, when, and any DNS or timeout failures along the way. Comparing date output in the guest against the host tells you instantly how far apart the two clocks are — an 11-day gap right after a saved-state restore or a host with a wrong clock is a strong clue.
Forcing an immediate resync
The cleanest nudge on an Ubuntu 24.04 desktop is the timedatectl toggle, because it works regardless of which service sits behind it:
sudo timedatectl set-ntp false
sudo timedatectl set-ntp trueDisabling NTP stops the client; re-enabling starts a fresh cycle that queries the servers right away instead of waiting out the old back-off timer. The equivalent low-level action is restarting the unit itself:
sudo systemctl restart systemd-timesyncdIf you have replaced timesyncd with chrony, the equivalent nudge is chronyc makestep, which steps the clock to the best available source immediately.
Verifying the fix took
After the nudge, re-run timedatectl and check that the synchronized flag is yes and — more importantly — that the displayed time matches an independent reference. A "Synchronized to time server" line in the journal confirms the exchange actually happened. For offsets of hours or days, timesyncd steps the clock outright rather than slewing it slowly, so the correction is instantaneous once a server responds.
VMs should have exactly one clock authority
Inside a VirtualBox guest there are two candidates for setting the time: the Guest Additions host-time sync and the guest's own NTP client. Both stepping the clock at once makes behaviour unpredictable, so pick one:
- Guest Additions sync. Install the Additions and let the guest follow the host clock. Corrections are applied periodically and immediately after a suspend/resume or saved-state restore — exactly when VM clocks go wrong. The catch: the guest is only as correct as the host, so the host itself must run NTP.
- In-guest NTP. Leave
systemd-timesyncdenabled and stop the Additions from touching the clock:
VBoxManage setextradata "VM name" "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" 1The first option is simplest for a desktop VM whose host is properly synced. Keep in-guest NTP if the host clock cannot be trusted, or if the guest must stay correct even when the host is not.
Preventing the slow first sync
You can shorten the path to a correct clock at boot by giving timesyncd explicit, reliable servers instead of relying on distro fallbacks. Edit /etc/systemd/timesyncd.conf:
[Time]
NTP=ntp.ubuntu.com
FallbackNTP=time.google.comthen run sudo systemctl restart systemd-timesyncd. Also confirm the host clock is itself synced — run timedatectl on the host — because every guest boots from that clock. If a machine regularly wakes with a huge offset and you need guaranteed instant correction, chrony with its makestep directive is the more assertive tool.
Frequently Asked Questions
Is toggling set-ntp off and on risky?
No. It only stops and restarts the NTP client; it never edits the clock directly or touches your files. The worst case is that the clock stays wrong until a server responds.
Why did timedatectl claim synchronization while the clock was 11 days off?
The flag reflects the last successful sync. If the guest had synced earlier and then sat in a saved state, the flag remained "yes" while the clock silently fell behind.
Should I replace systemd-timesyncd with chrony?
For a desktop, timesyncd is usually sufficient. Choose chrony if you need faster corrections after long pauses, detailed offset logging, or if the machine must serve time to others.
How do I check whether Guest Additions time sync is active?
Confirm the Additions are installed and that the VBoxService process is running in the guest (ps aux | grep -i vboxservice). If it is and in-guest NTP is disabled, the guest clock follows the host.
Sync keeps failing — what should I look at?
Read journalctl -u systemd-timesyncd. DNS resolution failures point at network configuration; repeated timeouts suggest a firewall blocking outbound UDP port 123 or a captive portal intercepting traffic.
Can a wrong clock break anything besides websites?
Yes. TLS certificate validation, package signature checks, scheduled jobs, and authentication tokens all depend on sane time, so fix the clock before debugging unrelated errors.