From: Frantisek Sumsal <frantisek@sumsal.cz>
Date: Fri, 7 Nov 2025 16:02:09 +0000 (+0100)
Subject: test: move the system time to exactly the timer's elapse time
X-Git-Tag: v259-rc1~133
X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=6d510012b7060174be0c364976c797dfea552309;p=thirdparty%2Fsystemd.git

test: move the system time to exactly the timer's elapse time

When we moved the time to 1 minute after the timer would've elapsed,
systemd could pick RandomizedDelaySec= <= 1 minute which would then
cause the timer to elapse immediately and the InactiveExitTimestamp=
to get recalculated including a new next elapse time that would be for
the next "window":

systemd[1]: timer-RandomizedDelaySec-30785.timer: Adding 3.634672s random time.
systemd[1]: timer-RandomizedDelaySec-30785.timer: Realtime timer elapses at Fri 2025-11-07 00:10:03 UTC.
systemd[1]: timer-RandomizedDelaySec-30785.timer: Timer elapsed.
systemd[1]: timer-RandomizedDelaySec-30785.timer: Changed waiting -> running
systemd[1]: Found unit timer-RandomizedDelaySec-30785.timer at /run/systemd/system/timer-RandomizedDelaySec-30785.timer (regular file)
systemd[1]: Preset files say disable timer-RandomizedDelaySec-30785.timer.
systemd[1]: timer-RandomizedDelaySec-30785.timer: Got notified about unit deactivation.
systemd[1]: timer-RandomizedDelaySec-30785.timer: Adding 8h 39min 26.166418s random time.
systemd[1]: timer-RandomizedDelaySec-30785.timer: Realtime timer elapses at Sat 2025-11-08 08:49:26 UTC.
systemd[1]: timer-RandomizedDelaySec-30785.timer: Changed running -> waiting
...
TEST-53-TIMER.sh[1008]: InactiveExitTimestamp=Thu 2025-11-06 23:00:00 UTC
TEST-53-TIMER.sh[1010]: ++ systemctl show -P NextElapseUSecRealtime timer-RandomizedDelaySec-30785.timer
TEST-53-TIMER.sh[905]: + NEXT_ELAPSE_REALTIME='Sat 2025-11-08 08:49:26 UTC'
TEST-53-TIMER.sh[1011]: ++ date '--date=Sat 2025-11-08 08:49:26 UTC' +%s
TEST-53-TIMER.sh[905]: + NEXT_ELAPSE_REALTIME_S=1762591766
TEST-53-TIMER.sh[905]: + : 'Next elapse timestamp should be Fri 2025-11-07 00:10:00 UTC <= Sat 2025-11-08 08:49:26 UTC <= Fri 2025-11-07 22:10:00 UTC'
TEST-53-TIMER.sh[905]: + assert_ge 1762591766 1762474200
TEST-53-TIMER.sh[1012]: + set +ex
TEST-53-TIMER.sh[905]: + assert_le 1762591766 1762553400
TEST-53-TIMER.sh[1013]: + set +ex
TEST-53-TIMER.sh[1013]: FAIL: '1762591766' > '1762553400'

Technically, the race is still there, but the window for it should be
_much_ smaller now (< 1s on a reasonably fast system). Let's hope that's
enough.

Resolves: #39594
---

diff --git a/test/units/TEST-53-TIMER.RandomizedDelaySec-reload.sh b/test/units/TEST-53-TIMER.RandomizedDelaySec-reload.sh
index eede7ae7c59..e9b9d4feeed 100755
--- a/test/units/TEST-53-TIMER.RandomizedDelaySec-reload.sh
+++ b/test/units/TEST-53-TIMER.RandomizedDelaySec-reload.sh
@@ -75,16 +75,16 @@ check_elapse_timestamp() {
 systemctl restart "$UNIT_NAME.timer"
 check_elapse_timestamp
 
-# Bump the system date to 1 minute after the original calendar timer would've expired (without any random
-# delay!) - systemd should recalculate the next elapse timestamp with a new randomized delay, but it should
-# use the original inactive exit timestamp as a "base", so the final timestamp should not end up beyond the
-# original calendar timestamp + randomized delay range.
+# Bump the system date to exactly the original calendar timer time (without any random delay!) - systemd
+# should recalculate the next elapse timestamp with a new randomized delay, but it should use the original
+# inactive exit timestamp as a "base", so the final timestamp should not end up beyond the original calendar
+# timestamp + randomized delay range.
 #
 # Similarly, do the same check after doing daemon-reload, as that also forces systemd to recalculate the next
 # elapse timestamp (this goes through a slightly different codepath that actually contained the original
 # issue).
 : "Next elapse timestamp after time jump"
-date -s "tomorrow 00:11"
+date -s "tomorrow 00:10"
 check_elapse_timestamp
 
 : "Next elapse timestamp after daemon-reload"