Bug#1033540: systemd: backport patch to fix a calendar spec calculation hang on DST change if TZ=Europe/Dublin

[Thomas Lamprecht]

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