🚨 Linux Error Guide: 'Clock skew detected' in make — Fix File Times in the Future

Overview

make compares file modification times to decide what to rebuild, and warns when it sees a file stamped in the future relative to the current clock:

make: Warning: File 'main.c' has modification time 42 s in the future
make: warning:  Clock skew detected.  Your build may be incomplete.

The same underlying condition shows up from other tools that reason about time:

tar: ./app.log: time stamp 2026-07-09 14:22:31 is 118 s in the future
find: warning: your system clock is wrong

The message means the system clock and the timestamps on the files disagree: either the clock jumped backward (NTP correction, a VM resume, a wrong timezone/RTC) or the files carry future timestamps (created on a host whose clock was ahead, or on an NFS server that’s out of sync with the client). make may then rebuild too much, too little, or loop.

Symptoms

• make prints “Clock skew detected” and possibly “Your build may be incomplete.”
• Builds rebuild everything every time, or skip targets that should rebuild.
• tar, find, or rsync warn about timestamps in the future.
• The host recently booted, resumed from suspend, or had its clock corrected by NTP.
• Files edited on an NFS mount trigger the warning while local files don’t.

Common Root Causes

• System clock is behind the files. NTP just stepped the clock backward, or the RTC/hardware clock was wrong at boot, so existing files look “future.”
• Wrong timezone or RTC-in-localtime confusion. A machine treating the hardware clock as local vs UTC can be hours off.
• NFS client/server clock mismatch. Files are stamped by the server’s clock; if it’s ahead of the client, make on the client sees future times.
• VM/container time drift. A guest whose clock wasn’t synced, or a suspended VM that resumed with a stale clock.
• Files copied from a machine with a fast clock, preserving future mtimes (cp -p, rsync -t, extracted archives).
• No time sync running at all on a freshly provisioned host.

Diagnostic Workflow

Compare the current clock to the offending files. First, what does the system think the time is, and is sync healthy?

timedatectl status                 # local/UTC, NTP synchronized?, RTC in local TZ?
date -u; date

Check the NTP/chrony sync state and offset:

chronyc tracking 2>/dev/null || timedatectl show-timesync 2>/dev/null
chronyc sources -v 2>/dev/null

Find how far into the future the files actually are:

ls --full-time main.c            # file mtime vs `date`
find . -newermt 'now' -printf '%TY-%Tm-%Td %TT %p\n' | head   # files stamped after 'now'

If it’s NFS, compare the two clocks directly:

date                              # on the client
ssh nfs-server date               # on the server; they should match closely

Example Root Cause Analysis

A CI worker started emitting make: warning: Clock skew detected on nearly every build, and builds became unreliable — sometimes recompiling the whole tree, sometimes shipping stale objects.

timedatectl status on the worker showed System clock synchronized: no and NTP service: inactive; the freshly-provisioned VM had never had time sync enabled. Its clock had drifted ~90 seconds behind real time. Meanwhile the source tree lived on an NFS share whose server was correctly NTP-synced, so every checked-out file carried an accurate (and therefore “future”) mtime relative to the lagging client — exactly the condition make warns about.

Enabling and starting chrony (systemctl enable --now chronyd) and letting it step the clock forward brought the worker within milliseconds of the NFS server. The skew warnings stopped immediately. For the already-checked-out tree, a one-time find . -exec touch {} + normalized timestamps so the current build wouldn’t over- or under-build. The root fix — time sync in the base image — prevented recurrence across the fleet.

Prevention Best Practices

• Run chrony (or systemd-timesyncd) on every host and verify timedatectl shows the clock synchronized; bake it into base images.
• Set the timezone and RTC convention explicitly (timedatectl set-timezone, keep RTC in UTC) so a wrong offset never masquerades as skew.
• Keep NFS servers and clients on the same time source; build hosts and file servers must agree closely.
• Sync time early in provisioning, before checkouts and builds, so no files are ever created against a wrong clock.
• For VMs, enable guest time sync / re-sync on resume so suspended builders don’t wake with a stale clock.

Quick Command Reference

# Is the clock correct and synchronized?
timedatectl status
chronyc tracking

# Enable time sync (chrony) and step immediately
sudo systemctl enable --now chronyd
sudo chronyc makestep

# Or systemd-timesyncd
sudo timedatectl set-ntp true

# Fix timezone / RTC convention
sudo timedatectl set-timezone UTC
sudo timedatectl set-local-rtc 0

# Normalize future timestamps on an already-checked-out tree
find . -newermt 'now' -exec touch {} +

Conclusion

“Clock skew detected” means make found files stamped in the future relative to the system clock — usually because the host’s time is wrong or lagging, often against an NFS server that keeps accurate time. Check timedatectl and chrony first, enable time sync so the clock steps to correct, and fix the timezone/RTC convention if the offset is large. Keep every host — especially build workers and file servers — on the same time source, sync early in provisioning, and the skew warnings and unreliable builds disappear.