Package: systemd Version: 247.3-7+deb11u1 Severity: important Dear Maintainer,
We (Proxmox) got quite a few reports over the weekend of stuck systemd processes, seemingly hung on calendar spec calculations. After a investigation it stuck out the only the Europe/Dubline time zone seemed affected. We then found a simple reproducer and a patch from newer systemd releases, which we backported and are in the process of rolling out broadly in our downstream distro. Note that one requires to have a timer configured over a specific calendar spec falling into the DST change time for this to trigger, so not all systems with timezone set to Europe/Dublin ran into it. So for current stable Debian Bullseye, please backport a fix [0] for systemd calendarspec calculation that triggers for the Europe/Dublin time zone, which handles DST changes in reverse (their summer time is their standard time and their winter time is like a negative-DST so to say). With [0] applied and systemd rebuild, the for the current year adapted reproducer mentioned in the commit message from [0] is fixed: TZ=Europe/Dublin faketime 2023-03-26 systemd-analyze calendar --iterations=5 'Sun *-*-* 01:00:00' Upstream has backported [0] already for their v247-stable branch in the v247.5 stable release and regression potential seems rather small here. For the sake of completness, systemd-stable backported also another more general safety net, which aborts the date normalization loop after maximal 1000 iterations [1], while this is not required for the specific bug, it's a good safety net in general and we back ported it too to our downstream systemd. cheers Thomas [0]: https://github.com/systemd/systemd-stable/commit/129cb6e249bef30dc33e08f98f0b27a6de976f6f [1]: https://github.com/systemd/systemd-stable/commit/f14b80e09e225ccf7cfd8a85578b7e64c3fdebb9
