shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2025-01-09 01:18:19 +03:00
Code
5b1aa0e19a
systemd/test/units/testsuite-53.sh

32 lines
821 B
Bash
Raw Normal View History

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-11 00:24:00 +03:00
#!/usr/bin/env bash
tests: add spdx headers to scripts and Makefiles
2021-10-17 19:13:06 +03:00
# SPDX-License-Identifier: LGPL-2.1-or-later
test: use set -eux and set -o pipefail everywhere This should make the scripts more robust.
2021-04-09 20:39:41 +03:00
set -eux
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-11 00:24:00 +03:00
set -o pipefail
test: use an explicit no-op for file truncation
2021-04-09 20:52:46 +03:00
: >/failed
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-11 00:24:00 +03:00
# Reset host date to current time, 3 days in the past.
date -s "-3 days"
Revert "Fix issue with system time set back (#24131)" This fix unfortunately introduced a much worse regression that is affecting many users, so let's revert it for now and rework it in the next release. This reverts commit 5ded3917a161d87984d74d70b5eb2a254e54b44e. Fixes https://github.com/systemd/systemd/issues/24984
2022-10-20 16:01:09 +03:00
# Run a timer for every 15 minutes.
systemd-run --unit test-timer --on-calendar "*:0/15:0" true
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-11 00:24:00 +03:00
Revert "Fix issue with system time set back (#24131)" This fix unfortunately introduced a much worse regression that is affecting many users, so let's revert it for now and rework it in the next release. This reverts commit 5ded3917a161d87984d74d70b5eb2a254e54b44e. Fixes https://github.com/systemd/systemd/issues/24984
2022-10-20 16:01:09 +03:00
next_elapsed=$(systemctl show test-timer.timer -p NextElapseUSecRealtime --value)
next_elapsed=$(date -d "${next_elapsed}" +%s)
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-11 00:24:00 +03:00
now=$(date +%s)
Revert "Fix issue with system time set back (#24131)" This fix unfortunately introduced a much worse regression that is affecting many users, so let's revert it for now and rework it in the next release. This reverts commit 5ded3917a161d87984d74d70b5eb2a254e54b44e. Fixes https://github.com/systemd/systemd/issues/24984
2022-10-20 16:01:09 +03:00
time_delta=$((next_elapsed - now))
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-11 00:24:00 +03:00
# Check that the timer will elapse in less than 20 minutes.
Revert "Fix issue with system time set back (#24131)" This fix unfortunately introduced a much worse regression that is affecting many users, so let's revert it for now and rework it in the next release. This reverts commit 5ded3917a161d87984d74d70b5eb2a254e54b44e. Fixes https://github.com/systemd/systemd/issues/24984
2022-10-20 16:01:09 +03:00
((0 < time_delta && time_delta < 1200)) || {
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-11 00:24:00 +03:00
echo 'Timer elapse outside of the expected 20 minute window.'
Revert "Fix issue with system time set back (#24131)" This fix unfortunately introduced a much worse regression that is affecting many users, so let's revert it for now and rework it in the next release. This reverts commit 5ded3917a161d87984d74d70b5eb2a254e54b44e. Fixes https://github.com/systemd/systemd/issues/24984
2022-10-20 16:01:09 +03:00
echo " next_elapsed=${next_elapsed}"
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-11 00:24:00 +03:00
echo " now=${now}"
Revert "Fix issue with system time set back (#24131)" This fix unfortunately introduced a much worse regression that is affecting many users, so let's revert it for now and rework it in the next release. This reverts commit 5ded3917a161d87984d74d70b5eb2a254e54b44e. Fixes https://github.com/systemd/systemd/issues/24984
2022-10-20 16:01:09 +03:00
echo " time_delta=${time_delta}"
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-11 00:24:00 +03:00
echo ''
Revert "Fix issue with system time set back (#24131)" This fix unfortunately introduced a much worse regression that is affecting many users, so let's revert it for now and rework it in the next release. This reverts commit 5ded3917a161d87984d74d70b5eb2a254e54b44e. Fixes https://github.com/systemd/systemd/issues/24984
2022-10-20 16:01:09 +03:00
} >>/failed
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-11 00:24:00 +03:00
Revert "Fix issue with system time set back (#24131)" This fix unfortunately introduced a much worse regression that is affecting many users, so let's revert it for now and rework it in the next release. This reverts commit 5ded3917a161d87984d74d70b5eb2a254e54b44e. Fixes https://github.com/systemd/systemd/issues/24984
2022-10-20 16:01:09 +03:00
if test ! -s /failed ; then
rm -f /failed
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-11 00:24:00 +03:00
touch /testok
fi
Copy Permalink