Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd
A patch was sent out today to the Linux kernel mailing list that would hide the "debug" string from showing up within the /proc/cmdline output. Why? To workaround a systemd bug. This has set off Linus Torvalds on another epic tirade.
When systemd sees "debug" as part of the kernel command-line, it will spit out so much informaiton about the system that it fails to boot... The init system just collapses the system with too much information being sent to the dmesg when seeing the debug option as part of the kernel command-line parameter. Within the systemd bug report it was suggested for systemd not to look for a simple "debug" string to go into its debug mode but perhaps something like "systemd.debug" or other namespaced alternatives. The debug kernel command-line parameter has been used by upstream Linux kernel developers for many years. However, upstream systemd developers don't agree about changing their debug code detection. Kay Sievers of Red Hat wrote, "Generic terms are generic, not the first user owns them."
When criticism was raised on the FreeDesktop.org bug report about this issue, systemd developers warned users not to discuss this matter on the BugZilla but to move to a mailing list or other discussion channels. Steven Rostedt ended up sending to the Linux kernel mailing list a patch that would hide the debug string from appearing in the kernel command-line as to hide it from systemd and reserve it just for kernel use. Steven wrote, "we OWN the kernel command line, and as such, we can keep the users from seeing stuff on it if we so choose. And with that, I propose this patch, which hides 'debug' from /proc/cmdline, such that we don't have to worry about tools parsing for it and causing hardship for those trying to debug the kernel."
That's where we now get another tirade by Linus Torvalds bashing systemd developers for making kernel developers work around their problems. Linus says he will refuse to merge any code from Red Hat's Kay Sievers until their code is cleaned up and not constantly causing problems. This will be a big problem since systemd developers are currently pushing for KDBUS as a kernel-based D-Bus implementation, and Linus made it clear to Greg Kroah-Hartman in the mailing list message that it will not be accepted until it's proven stable. Linus also said, "I'm not willing to merge something where the maintainer is known to not care about bugs and regressions and then forces people in other projects to fix their project. Because I am *not* willing to take patches from people who don't clean up after their problems, and don't admit that it's their problem to fix."
Key, I'm f*cking tired of the fact that you don't fix problems in the code *you* write, so that the kernel then has to work around the problems you cause.
Greg - just for your information, I will *not* be merging any code from Kay into the kernel until this constant pattern is fixed.
This has been going on for *years*, and doesn't seem to be getting any better. This is relevant to you because I have seen you talk about the kdbus patches, and this is a heads-up that you need to keep them separate from other work. Let distributions merge it as they need to and maybe we can merge it once it has been proven to be stable by whatever distro that was willing to play games with the developers.
But I'm not willing to merge something where the maintainer is known to not care about bugs and regressions and then forces people in other projects to fix their project. Because I am *not* willing to take patches from people who don't clean up after their problems, and don't admit that it's their problem to fix.
Kay - one more time: you caused the problem, you need to fix it. None of this "I can do whatever I want, others have to clean up after me" crap.
Andrew Morton also said on the kernel mailing list about this issue, "I had to check the date on this but surprisingly, it's all post April 1."
Other developers have even expressed support of signaling BUG_ON when systemd is detected, the compiler macro that will cause a kernel panic and halt the system.
Linus said in a follow-up email:
[System services parsing /proc/cmdline is fine but] does become a problem when you have a system service developer who thinks the universe revolves around him, and nobody else matters, and people sending him bug-reports are annoyances that should be ignored rather than acknowledged and fixed. At that point, it's a problem.
It looks like Greg has stepped in as a baby-sitter for Kay, and things are going to be fixed. And I'd really like to avoid adding hacky code to the kernel because of Kay's continued bad behavior, so I hope this works. But it's really sad that things like this get elevated to this kind of situation, and I personally find it annoying that it's always the same f*cking primadonna involved.
Well known kernel developer H. Peter Anvin also said in the original bug report, "This is utterly ridiculous, and it matches what I have observed that the system becomes undebuggable on a dracut/systemd system. There are a lot of things I genuinely like about systemd, but this aspect is a disaster."
This news comes just hours after we wrote about systemd's networkd is working on its own DHCP server and client.