1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd

systemd

Published on 02 April 2014 09:46 PM EDT
Written by Michael Larabel in systemd
246 Comments

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.

Linus


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.

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux Hardware Reviews
  1. Even With Re-Clocking, Nouveau Remains Behind NVIDIA's Proprietary Linux Driver
  2. The Power Consumption & Efficiency Of Open-Source GPU Drivers
  3. AMD R600g/RadeonSI Performance On Linux 3.16 With Mesa 10.3-devel
  4. Intel Pentium G3258 On Linux
Latest Linux Articles
  1. AMD Catalyst 14.6 Does Slightly Better With APITest OpenGL Tests
  2. Updated Source Engine Benchmarks On The Latest AMD/NVIDIA Linux Drivers
  3. Nouveau vs. Radeon vs. Intel Tests On Linux 3.16, Mesa 10.3-devel
  4. KVM Benchmarks On Ubuntu 14.10
Latest Linux News
  1. KDE 4.14 Release Candidate Ships
  2. Drivers & Drama Dominated Linux Talk In July
  3. Fedora Assembles A Security Team
  4. AMD Launches The A10-7800, The 65 Watt Kaveri
  5. Builder: A New Development IDE Being Built For GNOME
  6. GDB 7.8 Betters Python Scripting, Adds Guile Support
  7. GNOME's GTK+ Is Still Striving For A Scene Graph, Canvas API
  8. Unreal Tournament Looks Great For Team Deathmatch
  9. LibreOffice 4.3 Released With Many Exciting Changes
  10. GNOME/GTK On Wayland Gains Focus At GUADEC
Latest Forum Discussions
  1. Linus Torvalds On GCC 4.9: Pure & Utter Crap
  2. Grand Theft Auto Running On Direct3D Natively On Linux Shows Gallium3D Potential
  3. Debian + radeonsi
  4. AMD Publishes Open-Source Linux HSA Kernel Driver
  5. Open-source drivers on ATI R7 260X
  6. AMD Athlon 5350 APU On Linux
  7. Updated and Optimized Ubuntu Free Graphics Drivers
  8. List of Linux friendly Kickstarter projects