Bug#1033548: 02:00 timers dont run in DST transition night
Control: close -1 On Sun, 29 Oct 2023 23:24:54 +0100 Michael Biebl wrote: > Control: forwarded -1 https://github.com/systemd/systemd/issues/5595 > > I think the above upstream issue pretty much describes what you are > seeing, so marking as forwarded accordingly. This is tracked upstream, there are no patches nor configuration downstream, closing. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1033548: 02:00 timers dont run in DST transition night
On Sun, Oct 29, 2023 at 11:24:54PM +0100, Michael Biebl wrote: > I think the above upstream issue pretty much describes what you are seeing, > so marking as forwarded accordingly. It does. It also nicely reflects upstream's attitude "Yes, you're holding it wrong, and we don't care how ugly your workarounds might be as long as we don't have to code anything". Greetings Marc, who will probably just avoid 1.59-3.01 am for the rest of life -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1033548: 02:00 timers dont run in DST transition night
Control: forwarded -1 https://github.com/systemd/systemd/issues/5595 I think the above upstream issue pretty much describes what you are seeing, so marking as forwarded accordingly. Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1033548: 02:00 timers dont run in DST transition night
On Sat, Aug 26, 2023 at 02:41:23PM +0200, Michael Biebl wrote: > What was/is the output of > systemctl list-timers > before and after such a (DST) time jump? No clue, sorry. I just noticed that the timers didn't run. In aide, I have worked around that by moving the jo to 01:50. That is a good enough fix for me for the moment. > I.e., is there a way to reproduce this somehow? I think it would be possible by establishing a timer to 02:00 and setting the time to DST night. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1033548: 02:00 timers dont run in DST transition night
Control: tags -1 + moreinfo Hi Marc On Mon, 27 Mar 2023 11:29:32 +0200 Marc Haber wrote: Package: systemd Version: 252.6-1 Severity: minor Hi, aide-common ships the following timer: [Unit] Description=Daily AIDE check [Timer] OnCalendar=*-*-* 02:00:00 RandomizedDelaySec=2h Persistent=true [Install] WantedBy=timers.target This didn't run in DST transition night. I think this might be caused by the clock jumping from 01:59 to 03:00, with 02:00 not existing. Is there a notation to have a systemd timer run even if the exact time the timer is supposed to run doesn't happen? I guess this might also be the case in case of a grossly misticking clock and a timesync daemon stepping the time, for example, from 01:59:50 to 02:02:00? Or would be probably be a better idea to trigger a timer if systemd finds the trigger time in the past without the timer having been triggered? Not running at all came as kind of surprise for me. I might be holding things wrong but I'd like your opinion. What was/is the output of systemctl list-timers before and after such a (DST) time jump? I.e., is there a way to reproduce this somehow? OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1033548: 02:00 timers dont run in DST transition night
Package: systemd Version: 252.6-1 Severity: minor Hi, aide-common ships the following timer: [Unit] Description=Daily AIDE check [Timer] OnCalendar=*-*-* 02:00:00 RandomizedDelaySec=2h Persistent=true [Install] WantedBy=timers.target This didn't run in DST transition night. I think this might be caused by the clock jumping from 01:59 to 03:00, with 02:00 not existing. Is there a notation to have a systemd timer run even if the exact time the timer is supposed to run doesn't happen? I guess this might also be the case in case of a grossly misticking clock and a timesync daemon stepping the time, for example, from 01:59:50 to 02:02:00? Or would be probably be a better idea to trigger a timer if systemd finds the trigger time in the past without the timer having been triggered? Not running at all came as kind of surprise for me. I might be holding things wrong but I'd like your opinion. Greetings Marc -- Package-specific info: -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.2.8-zgsrv20080 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii libacl12.3.1-3 ii libaudit1 1:3.0.9-1 ii libblkid1 2.38.1-5+b1 ii libc6 2.36-8 ii libcap21:2.66-3 ii libcryptsetup122:2.6.1-3 ii libfdisk1 2.38.1-5+b1 ii libgcrypt201.10.1-3 ii libkmod2 30+20221128-1 ii liblz4-1 1.9.4-1 ii liblzma5 5.4.1-0.2 ii libmount1 2.38.1-5+b1 ii libp11-kit00.24.1-2 ii libseccomp22.5.4-1+b3 ii libselinux13.4-1+b5 ii libssl33.0.8-1 ii libsystemd-shared 252.6-1 ii libsystemd0252.6-1 ii libzstd1 1.5.4+dfsg2-5 ii mount 2.38.1-5+b1 Versions of packages systemd recommends: ii dbus [default-dbus-system-bus] 1.14.6-1 ii ntpsec [time-daemon]1.2.2+dfsg1-1 Versions of packages systemd suggests: ii libfido2-1 1.12.0-2+b1 pn libqrencode4 pn libtss2-esys-3.0.2-0 pn libtss2-mu0 pn libtss2-rc0 pn polkitd | policykit-1 pn systemd-boot pn systemd-container pn systemd-homed ii systemd-resolved 252.6-1 pn systemd-userdbd Versions of packages systemd is related to: pn dbus-user-session pn dracut ii initramfs-tools0.142 pn libnss-systemd ii libpam-systemd 252.6-1 ii udev 252.6-1 -- no debconf information
