Indeed, would that it were so.

Linus and others on the kernel dev team stated that kernel debugging was left open to flags that they hadn't guessed at, assuming Linux people would be grateful for the flexibility and responsible for "taking out their own trash". I have yet to replicate the issue but it is my understanding that the output generated by systemd, at least in this case, is absolutely useless data, literally useless, nobody can use it. So no gain but big problem..... much like my "ludicrous" analogy of a rock allowed to stay in the channel that serves no useful function but can sink hapless boats.

What strikes me as truly ludicrous is the apologetic attitude you display toward these two who have a history of utter arrogance and denial, not to mention creating bugs they refuse to fix, blaming everyone else. Furthermore Poettering has referred to Linux as a whole and the kernel dev team as "toys" and "cliques playing with toys" as well as referring to OSX as a "real OS, not a toy like Linux" and lastly compares systemd to dependency-resolving package managers for the init system. Choose what side as you will and for whatever reasons you fancy, even call me or anyone who disagrees with you ludicrous and "nothing reasonable" (hmmmmm... why does that sound familiar?) but we shall see very soon whether you chose well or not, and we all will be judged by that in the community. Hope you considered carefully. I did.

Yes, it was a systemd bug. No-one outside the systemd development team has ever suggested or acknowledged that this could be considered a kernel bug. Claiming otherwise is disingenuous.

Rate-limiting /dev/kmsg offers protection against malicious and defective processes; it's neither a bug fix nor the addition of an obviously-useful-but-previously-overlooked feature.

Any process with root privileges can crash the system, and PID 1 can cause a crash simply by exiting. The next systemd bug that causes a kernel panic will also be a systemd bug, not a kernel bug.

Thanks TobiSGD I always need to get my eyes together. the module loading service http://www.freedesktop.org/software/...d.service.html

Then the wish list. http://www.freedesktop.org/software/...n/systemd.html

Only one company I know personally put a broken operating system on the main communication servers and devices IBM and new that the next update would not fix it. As for my retired friends from Corning keep smiling it does not matter what system IBM uses they like to break it so only they can use it.

I am sure kernel org love big blue. And I am sure Linux Foundation goes where the money is. And I am sure Linus likes being paid every one should. So let the Dev's have fun http://www.linuxfoundation.org/news-...-power-systems But don't forget. The last Time a bicycle was actually made for the customer was 1955. After that it was all production.

Big bucks nothing is free monetarily.

Today we have a carbon fiber composite bike that cost much less to make, No Steel to roll, no need to hand braze like we do with formula racers still to this day. no putting them in a oven and taking all the molecules up to a certain temperature around 750 degrees so the molecules all settle the same. no need for a trained craftsman to follow every step and see it through. Not a big thing just your life.

What does this have to do with Systemd developers and a Lead kernel man that cusses like a Sailor. It is about quality and building it for the User.

Funny story actually :P
https://bugs.freedesktop.org/show_bug.cgi?id=76935#c22

It seems there was a bad assertion in their code that should (again, quote) have been fixed before the bug got to the kernel devs.. And that was causing all the spamming :) I thought, like you did, that it was fixed before hand (read it somewhere).. It seems it wasn't.. The non-bug, this is expected behavior thing was an improper assertion that probably, if not for all this Linus debate, would have remained unfixed.. :s That's kind of scary.

LE:
Ahh, and the fun part (quote from the above link):
And the bug history of the bug report: https://bugs.freedesktop.org/show_activity.cgi?id=76935

I'm not actually convinced there was a bug with the kernel, and before anyone says otherwise let me plead my case:

The debug flag was always set to allow an uninterrupted debugging output feedback from the kernel kmsg system. This was to allow continual debugging either to a verbose console or to a log file to track problems and bad code.

For 20 years this was never changed to where kernel debug output was ever questioned regardless of the init system. Every init system that has been around all have worked flawlessly with kmsg and debug as it was intended.

It was ONLY systemd that did so otherwise by continuously spamming kmsg. OpenRC, BSDinit, sysvinit, Runit, s6, daemontools, etc. none of them had any issues with kmsg and debug.

This leads me to believe this was not accidental, but intentional. For 20 years, one kernel developer feature remained as it was unchanged until systemd came along. This only proves that either systemd was broken by design, yet again, or the kmsg spam bug was not a bug but an intentional deliberate act to force the kernel developers to change something on their end that has never been changed for any reason.

I think, in my opinion, Linus needs to halt kernel developments completely and perform a full audit of the code to not only test this against other init systems, but equally against systemd and if systemd is found to be the only probable cause then all those involved with this action need to be immediately suspended from kernel developments and contributions until this can be investigated to prove otherwise, and if they are found guilty of attempting to tamper with kernel code, they and all involved need to be permanently banned from kernel code contributions, and then inquiries made into currently implemented code to exorcise it from the kernel and reverse out, possibly for the first time, code from the Linux kernel.

http://lkml.iu.edu//hypermail/linux/...4.0/02645.html

At least Steven Rostedt and Theodore T'so consider that this can be seen as kernel bug.

It is pretty simple: /dev/kmesg is the earliest way (before writable storage is mounted) to get logging working, which is a good thing for both, kernel and userspace developers. Bugs can happen all the time on both sides and it is good to have an early logging feature to actually find the bugs. If this logging feature crashes the whole system because something (even by accident) is logging to it then that defeats totally the purpose of this feature and it can be considered broken (aka: a bug is present).

This by the way is not the first time that logging problems appear due to spammy sub-systems, it happened before with some buggy in-kernel drivers. Guess what happened: the logging feature got a rate limit and nobody cared.

Most buggy drivers were always labeled as such Tobi, or they were assigned to the Staging drivers, given Unstable and/or Experimental status.

Just because there might be a bug the drivers don't immediately get moved to a different branch, rate-limiting is necessary anyways. Or as Linus put it:http://lkml.iu.edu//hypermail/linux/...4.0/01488.html

According to the LKML archive, Linus posted on April 2nd.
According to Bugzilla, the report was made on April 2nd.
Perhaps the systemd developers noticed the bug before April 2nd, nonetheless, according to the FDO GIT log, a fix was not committed until April 6th.
Let us assume what we will.

Like many other things in life, a cooperative tasking model can get more done per cycle than a preemptive one.

Users of the kernel logging module for 20 years applied the cooperative tasking model: Don't assume that you are the only user of the resource.

The systemd users assumed otherwise.

Make of that what you will.

From my experiences in a similar environment, that would be due to untrained monkeys writing code using a framework that they did not attempt to understand. Make of that what you will.

When you throw away all the gathered and consolidated knowledge that has been collected, and pieced together painstakingly since the beginning and trash all the standards just to say you can do it and try to do things without thinking on the consequences... this is the end result.

A thousand monkeys at a thousand keyboards...

See attachment...

That's not the bug fix.. That's only the change for the default target for logging after the early boot phase.

I'm not even going to start where that analogy is flawed, let me just say there are many and you really shouldn't use cars as an anology unless you have more than a basic idea about them.
2 completely different scenarios. If you stuffed your system playing with Alsa, knowing you shouldn't, that is already part of the system then it's your fault. If systemd showed a flaw in the kernel before it has been finalised then it appears the kernel needs a bit of patching to ensure the fault does not rear its ugly head again.

Which again begs the question why even make the analogy?

Crank up the dictionary again Apologetic. Let's get this perfectly clear, at no stage have I shown an apologetic attitude for "these two" as you call them. What I have done is displayed an attitude that reflects the ideals of FOSS. If something breaks or has a problem then fix it, simple. Apart from that I have not gone and said either side in this arguement is right or wrong. I agreed with Tobi and that was it. If you have a problem with a regular Linux user suggesting a problem gets fixed then guess what, it's your problem not mine.

I do not deny the man has a problem but I'm not going to go on a "rantage" about it. I'll leave that to you.

You're telling me to make a choice or be judged by the community! People are dying on this planet and countries are being pulled apart, possibly leading to another Eurpoean war and you're carrying on like this is the last choice anyone will make. Sorry but you've just shown yourself to be an extremist. I have no time for that.

Could this thread be moved out of the Slackware sub-forum? I don't see, where this is relevant to Slackware. Slackware doesn't use Systemd and is not affected by this issue. The "debug" kernel parameter works just fine and dandy.