Response to systemd's use of the debug flag
plus.google.com
Response to systemd's use of the debug flag
1–10 of 36 posts
Re: Response to systemd's use of the debug flag
#2>What I mind is people closing bugs and not admitting mistakes. If Kay had even said "sorry, the excessive output was a bug in systemd, it's already fixed in current -git", that would have been a valid reason to close the bug.
So Torvalds is saying he doesn't like dictatorial project maintainers who reply in an abrupt and abrasive manner to contributors? He is so concerned about the lack of politeness and professional discourse that he just had to raise this issue? Hilarious.
Re: Response to systemd's use of the debug flag
#3> At that point there is simply no other option for that, because persistent storage is not available
This was about overloading an already used option by another team building a core system component -- the kernel. A debug for kernel's command line is for the kernel.
> It's the option an admin can specify which tells him why the system doesnt boot,
Ok so he does and now his system also doesn't boot but now it is either because of the original problem or because it gets flooded by systemd logs.
And then, he goes and posts to the kernel mailing lists saying how kernel is a piece of shit.
> That turns this into some kind of power game, which I am totally not interested in.
also
> We are putting together an OS here after all, not just a kernel, and a kernel is just one component of the OS among many, and ultimately an implementation detail.
I think due to their attitude towards both testing, towards the kernel community, they shouldn't be building core system components. And did he just write that kernel is just "an implementation detail?".
Maybe systemd was a mistake. Integrating and dumping socket acceptors, logging, and the whole kitchen sink into one component. So when it breaks it really breaks.
Re: Response to systemd's use of the debug flag
#4Re: Response to systemd's use of the debug flag
#5Retweeting was a genius move by twitter, a post by someone you don't follow appears in your timeline and it looks like any other and attribution is perfectly captured.
Re: Response to systemd's use of the debug flag
#6I have a fair amount of experience with Linux, but I'm a little lost by what's going on here. Can someone out there dumb this down a bit for an init newbie?
In a nutshell. :)
Re: Response to systemd's use of the debug flag
#7Google+ really doesn't get retweeting, does it. That whole post is written by someone who isn't the one in the photos at the top. A single "originally shared" link points to the original. Retweeting was a genius move by twitter, a post by someone you don't follow appears in your timeline and it looks like any other and attribution is perfectly captured.
https://plus.google.com/+LennartPoetteringTheOneAndOnly/post...
Re: Response to systemd's use of the debug flag
#8I have a fair amount of experience with Linux, but I'm a little lost by what's going on here. Can someone out there dumb this down a bit for an init newbie?
systemd parses /proc/cmdline and if "debug" is set, it also raises it's log level to debug. Then systemd logs so much to the kernel log that it gets flooded and fails to boot.
Edit: And story wise, systemd says yeah, we're not going to fix this or rename the debug flag for systemd to "systemd.debug" because blah.
And Torvalds gets pissed.
Re: Response to systemd's use of the debug flag
#9Google+ really doesn't get retweeting, does it. That whole post is written by someone who isn't the one in the photos at the top. A single "originally shared" link points to the original. Retweeting was a genius move by twitter, a post by someone you don't follow appears in your timeline and it looks like any other and attribution is perfectly captured.
Totally agree. As things are currently, wouldn't it be best if the story link was to the actual original post? https://plus.google.com/+LennartPoetteringTheOneAndOnly/post...
Re: Response to systemd's use of the debug flag
#10I have a fair amount of experience with Linux, but I'm a little lost by what's going on here. Can someone out there dumb this down a bit for an init newbie?
The bug that started this all came up when someone had a broken system that was causing systemd to spew out tons of log messages. This was overwhelming the kernel message system and causing things to time out/etc and resulted in an unbootable system. When this problem got opened upstream, the systemd maintainer said "not my problem."
There are a couple of ways forward here: systemd can limit its own output and say "my bad"[1], systemd can begin looking for its own debug flag in the kernel command line instead of using the kernel's own debug flag or the kernel can implement rate limiting on the message system[2] to keep userspace from shooting itself in the foot.
Torvalds really doesn't like the systemd maintainer's "not my problem" attitude so he's threatened to no longer accept pull requests from him for any code he writes. Torvalds wrote a really good post in the linked Google+ comments that describes his feelings on the whole thing:
"I don't mind people piggy-backing on some fairly obvious generic term like "debug" per se. I don't know if the old init scripts did that, but I do know they did it for "quiet", which is basically the reverse of "debug".
What I mind is people closing bugs and not admitting mistakes. If Kay had even said "sorry, the excessive output was a bug in systemd, it's already fixed in current -git", that would have been a valid reason to close the bug.
And for the people thinking this is a storm in a teacup: this is not the first time Kay has done this, which is why I personally get so frustrated.
Kay has done the exact same thing with major bugs that were not fixed anywhere else, and that caused machines to fail at boot time, and Kay happily pointed the finger elsewhere for months at a time and closed bugzilla entries.
Side explanatory note: and it's because of that known history of abusive behavior that I would prefer systemd now use "systemd.debug".
The old init scripts may or may not have parsed "debug", but we never had any reason to care. Now we do, and people are (I think) understandably upset that systemd not only screwed up, but then the people involved weren't even willing to say "sorry" about it but instead go "uh, it wasn't our bug, deal with it"."
----
[1] This happened
[2] This will likely happen