Tom Horsley writes:
On Mon, 22 Mar 2021 08:22:46 -0400 Sam Varshavchik wrote:> This is complexity purely for the sake of having complexity, and introducing> more unneeded dependencies on the systemd monstrosity. Didn't this thread start with a warning about raid systems hanging at boot? What on earth does raid care what the timezone is? Does some raid header somewhere have timestamps recorded in local time to emulate Microsoft? :-).
You're preaching to the choir. If setting the timezone was no more than echo 'Asia/Seoul' >/etc/timezonethen how could this, in any way, end up breaking RAID? Even if that was done at the very exact time the raid daemon woke up?
I just saw, in the other message, the link to the github pull request to fix this. I rolled the dice and decided to look at it, and spend a few moments trying to figure what's up. It seems to be trying to derive epoch time for the next start time, something along those lines.
The existing algorithm fails and results in the infinite loop. The fix appears to be not to actually fix the algorithm, but to cap the number of iteration to 1000. And then there were also four more commits thrown in for a good measure, making various changes that seems to be somewhat random and unrelated to the bug. Hopefully, the first commit is good enough to fix the bug, and the rest won't create four new bugs in its place.
What struck me is this: the format of the zone files is documented. It's tzfile(5). I wrote a parser for it, some time ago. By parsing the zone file you would know when the timezone offset changes *and in which direction*. You can factor this in, when doing epoch time calculations. It would be nice if glibc exposed this data. It doesn't, but it's not hard to get at it yourself. It's puzzling why systemd didn't reinvent this wheel, given all the wheels it already reinvented.
Really, this should've been a deterministic calculation: compute the next run time, based on the calendar spec and the current time, and ignoring time shifts. Now, you've computed the epoch time for the next run time, on the assumption that there are no timezone changes. And what about them, well, you have a nice list of them, in the tzfile(5).
So, then you go through the tzfile(5), which gives you all the timezone changes between the two epoch times, and use the deltas to adjust your epoch time. And you end up at the right time. And if you land in the black hole, you'll just end up running the task at some particular point in time, and then regroup on the next run. And none of this heuristic guesswork to derive the epoch time, that has sooooo many opportunities to go sideways. Which it did.
Attachment:
pgpvypfAZfAJQ.pgp
Description: PGP signature
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
