systemd/test/TEST-53-ISSUE-16347/test.sh

#!/usr/bin/env bash
# SPDX-License-Identifier: LGPL-2.1-or-later
set -e

TEST_DESCRIPTION="test timer units when initial clock is ahead"
TEST_NO_NSPAWN=1

QEMU_OPTIONS+=" -rtc base=$(date -u +%Y-%m-%dT%H:%M:%S -d '+3 days')"

# shellcheck source=test/test-functions
. "${TEST_BASE_DIR:?}/test-functions"

do_test "$@"
timer: Adjust calendar timers based on monotonic timer instead of realtime When the RTC time at boot is off in the future by a few days, OnCalendar= timers will be scheduled based on the time at boot. But if the time has been adjusted since boot, the timers will end up scheduled way in the future, which may cause them not to fire as shortly or often as expected. Update the logic so that the time will be adjusted based on monotonic time. We do that by calculating the adjusted manager startup realtime from the monotonic time stored at that time, by comparing that time with the realtime and monotonic time of the current time. Added a test case to validate this works as expected. The test case creates a QEMU virtual machine with the clock 3 days in the future. Then we adjust the clock back 3 days, and test creating a timer with an OnCalendar= for every 15 minutes. We also check the manager startup timestamp from both `systemd-analyze dump` and from D-Bus. Test output without the corresponding code changes that fix the issue: Timer elapse outside of the expected 20 minute window. next_elapsed=1594686119 now=1594426921 time_delta=259198 With the code changes in, the test passes as expected. 2020-07-10 21:24:00 +00:00			`#!/usr/bin/env bash`
tests: add spdx headers to scripts and Makefiles 2021-10-17 16:13:06 +00:00			`# SPDX-License-Identifier: LGPL-2.1-or-later`
timer: Adjust calendar timers based on monotonic timer instead of realtime When the RTC time at boot is off in the future by a few days, OnCalendar= timers will be scheduled based on the time at boot. But if the time has been adjusted since boot, the timers will end up scheduled way in the future, which may cause them not to fire as shortly or often as expected. Update the logic so that the time will be adjusted based on monotonic time. We do that by calculating the adjusted manager startup realtime from the monotonic time stored at that time, by comparing that time with the realtime and monotonic time of the current time. Added a test case to validate this works as expected. The test case creates a QEMU virtual machine with the clock 3 days in the future. Then we adjust the clock back 3 days, and test creating a timer with an OnCalendar= for every 15 minutes. We also check the manager startup timestamp from both `systemd-analyze dump` and from D-Bus. Test output without the corresponding code changes that fix the issue: Timer elapse outside of the expected 20 minute window. next_elapsed=1594686119 now=1594426921 time_delta=259198 With the code changes in, the test passes as expected. 2020-07-10 21:24:00 +00:00			`set -e`

			`TEST_DESCRIPTION="test timer units when initial clock is ahead"`
			`TEST_NO_NSPAWN=1`

test: don't overwrite existing $QEMU_OPTIONS 2022-09-20 17:12:18 +00:00			`QEMU_OPTIONS+=" -rtc base=$(date -u +%Y-%m-%dT%H:%M:%S -d '+3 days')"`
test: make the test entrypoint scripts shellcheck-compliant 2021-04-19 11:01:59 +00:00
			`# shellcheck source=test/test-functions`
			`. "${TEST_BASE_DIR:?}/test-functions"`
timer: Adjust calendar timers based on monotonic timer instead of realtime When the RTC time at boot is off in the future by a few days, OnCalendar= timers will be scheduled based on the time at boot. But if the time has been adjusted since boot, the timers will end up scheduled way in the future, which may cause them not to fire as shortly or often as expected. Update the logic so that the time will be adjusted based on monotonic time. We do that by calculating the adjusted manager startup realtime from the monotonic time stored at that time, by comparing that time with the realtime and monotonic time of the current time. Added a test case to validate this works as expected. The test case creates a QEMU virtual machine with the clock 3 days in the future. Then we adjust the clock back 3 days, and test creating a timer with an OnCalendar= for every 15 minutes. We also check the manager startup timestamp from both `systemd-analyze dump` and from D-Bus. Test output without the corresponding code changes that fix the issue: Timer elapse outside of the expected 20 minute window. next_elapsed=1594686119 now=1594426921 time_delta=259198 With the code changes in, the test passes as expected. 2020-07-10 21:24:00 +00:00
test: "detect" the test number automagically Specifying the test number manually is tedious and prone to errors (as recently proven). Since we have all the necessary data to work out the test number, let's do it automagically. 2021-04-26 17:20:18 +00:00			`do_test "$@"`