Systemd catches up with bind events

Posted Nov 14, 2020 6:23 UTC (Sat) by marcH (subscriber, #57642)
Parent article: Systemd catches up with bind events

> Breaking systemd
> In July 2017, though, Dmitry Torokhov added two new event types called BIND and UNBIND.
> [...]
> Later that same month, a bug report landed in the KDE bug tracker; this was perhaps the first case where somebody noticed a problem related to the new events.

How can someone create new uevents in 2017 and not test them on a system running systemd?

I must have missed something...

to post comments

Systemd catches up with bind events

Posted Nov 14, 2020 7:17 UTC (Sat) by geuder (subscriber, #62854) [Link]

Test on *a* system running systemd might not be enough.

Haven't looked what 10-dm-disk rule really does nor how many other rules (in other distros?) are fatally affected by the same problem. While developer machines are not unlikely to use some basic LVM I doubt they typically have very fancy disk setups. I had failing udev rules before and it did not show up until later in some use case, not immediately preventing boot or all usage of the system.

Systemd catches up with bind events

Posted Nov 14, 2020 14:24 UTC (Sat) by mezcalero (subscriber, #45103) [Link] (1 responses)

What this article isnt mentioning is that the bind/unbind uevents wasnt used that much initially by subsystems, but that changed over time. Just having these new event types is one thing, actually firing them another. One is an architectural change without immediate effect on userspace. The other is a subsystem-specific "trickle-down" thing that breaks things slowly and piece-meal, and that actually affects userspace.

Systemd catches up with bind events

Posted Nov 14, 2020 18:10 UTC (Sat) by marcH (subscriber, #57642) [Link]

> What this article isnt mentioning is that the bind/unbind uevents wasnt used that much initially by subsystems, but that changed over time

Indeed, this is exactly my question: how much were these new uevents used and tested before submission? Again I might have missed something but I find this sentence (and patch) amazing:

> As a short-term "fix", systemd was patched to simply ignore the new events

I thought I read somewhere that every new kernel feature must come with "real" use cases where "real" means running code. Yet the first thing the main and... surprised (!) consumer of this new feature did was... discarding it! How come this was not immediately reverted for obvious lack of testing?

Many kernel patches get months and even sometimes years of out-of-tree test coverage before making it to the main line, some even ship on millions of commercial products before getting merged, so why/how was this patch expedited? Just because it had a small number of lines? I can write a one-line kernel patch with very bad consequences any day :-)

> Perhaps the real lesson here is that the community would be better served by closer relations between the kernel project and projects managing low-level utilities like systemd.

Better relationships can only help but in this particular case it seems like the much more basic, focused and technical question: "What tested this and how?" would have been at least as effective.

Systemd catches up with bind events

Posted Nov 14, 2020 22:09 UTC (Sat) by bnorris (subscriber, #92090) [Link]

> How can someone create new uevents in 2017 and not test them on a system running systemd?

For one, I'm pretty sure the author's day job involves a distribution that does not run systemd (the init system). But since this article is really about systemd-udevd (which said distribution does use), I guess that's beside the point ;)

But in a similar vein: the set of udev rules running on a given distribution may vary wildly, so just because a rule ships on certain systems (e.g., the Fedora 32 example in the article) doesn't mean the distribution the author was developing has problematic rules of a similar type.

Your question sounds more like, "how can someone not test with the udev rules provided by libmtp [1]?" To me, it sounds like an honest oversight, and not a lack of legitimate use case or testing. But I could be wrong.

[1] https://bugs.kde.org/show_bug.cgi?id=387454#c20