Clock skew on testbeds

Bug #1880839 reported by Balint Reczey on 2020-05-27
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Auto Package Testing
systemd (Ubuntu)

Bug Description

Clock stepped backward on a testbed:

context FAIL stderr: make[2]: Warning: File '/tmp/tmp.qPfGPM84a1/src/demo2.cpp' has modification time 0.52 s in the future
autopkgtest [13:55:37]: test context: - - - - - - - - - - stderr - - - - - - - - - -
make[2]: Warning: File '/tmp/tmp.qPfGPM84a1/src/demo2.cpp' has modification time 0.52 s in the future
make[2]: warning: Clock skew detected. Your build may be incomplete.

Balint Reczey (rbalint) wrote :

My suspect is systemd-timesyncd:

See src/timesync/timesyncd-manager.c:

 * Maximum delta in seconds which the system clock is gradually adjusted
 * (slewed) to approach the network time. Deltas larger that this are set by
 * letting the system time jump. The kernel's limit for adjtime is 0.5s.
#define NTP_MAX_ADJUST 0.4

I suspect the boost compilation's load made the internal clock diverge enough for systemd to jump the time.

The default PollIntervalMaxSec is 2048 seconds in systemd.

I can reduce it in systemd, but there is a jump as high as 0.85 in
which could not have been prevented by just halving the default.

How about changing the autopkgtest setup to either change a default or disable systemd-timesyncd or install chrony instead?

Balint Reczey (rbalint) wrote :

We have a few options to fix the issue. The one I'd prefer would be switching to systemd to depend on chrony as the preferred time-daemon because timesynd turns back time and that can cause issues like this one.

An other option is disabling systemd-timesyncd in the test VMs, that would make the tests more reproducible but less similar to real installations's behavour.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers