timesyncd: add maximum clock step policy

[dabirt]

Summary

• add an opt-in MaxClockStepSec= limit for the absolute offset accepted from one NTP response;
• ignore responses beyond the configured limit and continue with another server;
• expose the configured limit over D-Bus and document the RTC-less first-boot tradeoff; and
• preserve the existing behavior by defaulting to infinity.

This implements the policy control requested in #17782. A finite default is intentionally not proposed: systems without a reliable RTC may legitimately require a large initial correction. Administrators that have a trustworthy starting clock can now select an appropriate ceiling.

Testing

Tested from current main at 765dc9691be793e03b6b13b16bb834c0aa216c9e on a Debian testing ARM64 host:

ninja -C build test-timesync systemd-timesyncd
meson test -C build --print-errorlogs test-timesync

1/1 timesync - systemd:test-timesync OK

The unit coverage checks the unlimited default, the exact configured boundary, and positive and negative offsets beyond it. git diff --check and XML well-formedness checks also pass.

Closes #17782.

[dabirt]

Addressed the review in 29a4730:

• removed DEFAULT_MAX_CLOCK_STEP_USEC and initialize the field with USEC_INFINITY directly;
• renamed the setting and corresponding D-Bus/internal identifiers to MaxClockChangeSec= / MaxClockChangeUSec; and
• changed the warning to use FORMAT_TIMESPAN(..., USEC_PER_MSEC) with %s.

I also converted the newly added test assertions to the current ASSERT_* helpers while updating their names. git diff --check passes; the updated project CI is running.

[github-actions]

Claude review of PR #43117 (29a4730)

Suggestions

• USEC_INFINITY default is not truly unbounded — src/timesync/timesyncd-manager.c:367 — (double) USEC_INFINITY / USEC_PER_SEC yields a finite ~1.84e13 s threshold; short-circuit on USEC_INFINITY to mean "no limit" literally.
• D-Bus docs not regenerated — src/timesync/timesyncd-bus.c:218 — new MaxClockChangeUSec property is missing from the generated man/org.freedesktop.timesync1.xml.

Nits

• Default-infinity test doesn't exercise the real bound — src/timesync/test-timesync.c:40 — 1e9 is below the accidental finite threshold, so it doesn't verify infinity disables the check.

Workflow run

[github-actions]

Claude: suggestion: When max_clock_change_usec == USEC_INFINITY (the default), this does not compare against infinity. (double) USEC_INFINITY is the finite double 1.8446744073709552e19, so the threshold becomes ~1.844e13 seconds rather than truly unbounded, and any offset above that would be rejected even under the documented "infinity" default. In practice NTP offsets are bounded well below that, so existing behavior is preserved, but relying on that implicit bound is fragile and the code no longer literally means "no limit". Consider short-circuiting explicitly, e.g. if (m->max_clock_change_usec == USEC_INFINITY) return false; before the floating-point comparison, which also sidesteps the USEC_INFINITY / USEC_PER_SEC precision detail.

[github-actions]

Claude: suggestion: A new read-only D-Bus property MaxClockChangeUSec is added to the manager vtable, but the generated interface documentation in man/org.freedesktop.timesync1.xml is not updated to list it. That file is auto-generated (via tools/update-dbus-docs.py) and kept committed in sync with the exported interface; sibling t-typed const properties (RootDistanceMaxUSec, PollIntervalMinUSec, etc.) all appear there. Please regenerate/update it so the introspection docs match the exported interface.

[github-actions]

Claude: nit: The default-infinity assertion only exercises 1e9, which is far below the accidental finite threshold (~1.844e13 s) produced by (double) USEC_INFINITY / USEC_PER_SEC. It therefore does not actually verify that the default disables the check for arbitrarily large offsets. If the intent is that infinity means "never too large", consider asserting with an offset above that bound (e.g. 1e14); today such a value would incorrectly report too-large.

[yuwata]

CIs are unhappy.
Please also consider the report by Claude.