https://bugs.kde.org/show_bug.cgi?id=461713
Bug ID: 461713
Summary: Unexpected behavior occurs when certain alarm types
are set to trigger within an hour of Daylight Savings
Time ending.
Classification: Applications
Product: kalarm
Version: 3.5.2
Platform: OpenSUSE
OS: Linux
Status: REPORTED
Severity: major
Priority: NOR
Component: general
Assignee: djar...@kde.org
Reporter: mgui...@yahoo.com
Target Milestone: ---
Created attachment 153683
--> https://bugs.kde.org/attachment.cgi?id=153683&action=edit
Video showing the bug in action.
SUMMARY
They key problem seems to be alarms set to for recurrence. "One time" alarms
did not seem to cause a problem.
"Command Alarms", with "Daily Recurrence", set to trigger during the hour
before Daylight Savings Time ends will continually trigger. I also noticed a
spike in CPU usage for kalarm.
I marked as major severity because I imagine this could potentially cause
system instability if the command is CPU or resource intensive.
"Sound Alarms", with "Daily Recurrence", set to trigger during the hour before
Daylight Savings Time ends will continually trigger, but will wait until the
sound finishes playing before starting again. I also noticed near 100% cpu
usage for kalarm.
"Daily Recurrence" "Display Alarm" fails to display the alarm. kalarm shoots
to nearly 100% cpu usage.
Longer description of testing process in Additional Information section.
STEPS TO REPRODUCE
1. Set timezone to be a timezone that observes Daylight Savings Time. For
example, "America/New York"
2. Set system time to before the hour before Daylight Savings Time ends (2AM on
November 6th) so you can set an alarm for November 6th, sometime between 1 AM
and 2 AM. For example, " timedatectl set-time '2022-11-06 00:51:45' "
3. Create a "Command Alarm" set to trigger on November 6th, between 1AM and 2
AM. Alarm must have "Daily Recurrence" set. For example, 2022-11-06 01:52
4. Set system time to a few seconds before alarm trigger time. For example "
timedatectl set-time '2022-11-06 01:51:45' "
5. Wait until alarm trigger time.
OBSERVED RESULT
Command executes at set time but the alarm will continue to trigger as fast as
the system can handle. If the command completes before 251 processes are
created, it will trigger for an unknown length of time. If the command does
not complete, kalarm will throw an error once 251 processes are created.
EXPECTED RESULT
The command runs once at the expected time. However, how kalarm handles the
timezone change is debatable. It shouldn't run twice, but, in this example,
should it run at 1:52 AM before the time change, or 1:52 AM after the time
change.
WORKAROUND
Do not set alarms during the hour before the end of Daylight Savings Time.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: OpenSUSE Tumbleweed 20221110
(available in About System)
KDE Plasma Version: 5.26.3
KDE Frameworks Version: 5.99.0
Qt Version: 5.15.7
Kernel Version: 6.0.7-1-default (64-bit)
Graphics Platform: X11
ADDITIONAL INFORMATION
I have a daily recurrence command alarm set for around 1:55 AM that silently
starts recording TV. The command runs for around 1 hour. On November 6th,
once it triggered, I started getting errors stating the command failed. I also
noticed my system feeling sluggish. Upon investigating, I noticed a couple
hundred processes running that were the expected command. Killing them just
resulted in kalarm starting new ones. I had to pause the alarm to get things
settled.
In order to rule out any unique changes I've made to my system, I installed
Tumbleweed fresh in a VM and reproduced the bug.
I first used the following command to test:
while true; do touch ~/Testing/test-$(date +%Y%m%d%H%M%S%N) && sleep 60; done
It resulted in 251 processes starting, each running the command as expected.
Then kalarm would throw a "Failed to execute command".
To see what would happen if a command was run that would quickly complete, I
tested the following:
touch ~/Testing/test-$(date +%Y%m%d%H%M%S%N)
It resulted in over 1000 test files being created in the few seconds before I
disabled the alarm.
The above tests were run with an alarm set to "Daily Recurrence".
It seems alarms of all type that are set to "No Recurrence" do not trigger the
bug.
"Daily Recurrence" "Sound Alarms" will trigger the bug, however it manifests
differently.
It doesn't overlap playing of the sound, it will wait until the sound completes
before starting again. However, during this time kalarm shoots to nearly 100%
cpu usage.
"Daily Recurrence" "Display Alarm" fails to display the alarm. kalarm shoots
to nearly 100% cpu usage.
I do not have email set up in order to test "Email Alarms".
I have not tested what happens to an alarm set to go off in the hour that is
skipped at the start of Daylight Savings Time. However I would expect it would
just run at 2 AM unless it's set to "Cancel if late".
--
You are receiving this mail because:
You are watching all bug changes.
