Anything can be broken if you throw enough time, money, and energy into it, but there is no point in leaving a potential problem in something that can be fixed. I, unlike others it seems, don't subscribe to the idea that one more flaw is ok when the flaw can be fixed.

Just to make that clear, Linus has no problem with userspace software using the generic debug option, systemd is not the only userspace software that does that. At the point that discussion came up he simply didn't know that that bug was already fixed. And it is not really relevant to the discussion. At no point Linus had a problem with systemd, he has a problem with the way this bug report was handled by Kay Sievers. That is why he denies to accept patches from this guy for the kernel, until his behavior regarding bug handling (not coding style or anything else) is fixed.

SystemDux? Might be better all-round if P & S created that from scratch and left Linux alone.

2 members found this post helpful.

I use the KISS method 18 months ago the bug was found.

The developer on the project closed the bug said it was the kernel problem.

Well after looking at it the kernel developers over 18 months ago said nope your bug.

Your program created this environment so it is your bug.

The developer said nope take it to the forums.
The real problem is same as you get with pulse audio. never really fixed.

Is Systemd going to become a module in the kernel if I am wrong correct me.
And a option to build for the Red Hat folks.

So Greg A very much part of the kernel team had to fix Kay's stuff.

It is not for the Kernel developer to work on that. It is up to the developers to test test test.

Just think there is how many systems out there right now using a broken init. The Hacks are having fun.

The Kernel is more than one man. Linus has a lot of power. With power comes responsibility.

I my self do not see Him as anything more than another human on this earth.

As Adam Time said if your going to play in Linus sand box than you will have to deal with it.

Other wise the source it is free go make your own sand.

Actually, that is what I said. Linus (and not only) ended up asking them to use systemd.debug just because they don't trust them (yes, I ommited the part in which he won't accept any patches to the kernel from Kay, but that's irrelevant now, I think).. I'm not trying to twist anyones word on this and not saying he bashed the systemd project.. I'm not even commenting or expressing an opinion about the systemd project..

The fact remains that at the time of Linus's mail, the bug was already closed by Kay with a clear statement that 'That is the expected current behaviour, "debug" can cause "too many" messages to be useful anymore if things are broken.'.. That's a quote.. So, I'm fair to presume that he either knew this was already fixed but didn't bother to mention it (unlikely, judging by the response) or didn't know it's fixed but somehow decided it's not worth looking into..
At that point he suggested the use of 'loglevel=' since, of course, 'debug' is 'a convenience shortcut for the kernel AND the Base OS' even if it renders the entire debug process useless.

They are not the first init system, and somehow others thought it would be nice not to interfere with the current workflow.. Kay and Lennart don't see it, they must be equally important at all cost.. And the fact is they are, and that is the whole damn problem..

You can switch it however you like and say the kernel had a problem, that systemd had a problem, that they we're right to use 'debug' but that is quite irrelevant.. The whole point is that someone thought that if his project can't be debuged normally or with some amount of easiness, neither should the kernel be.. And even now, if you enter debug then systemd still needs to fill half (just a guess, I admit) of the entries, just so you don't forget it's there, albeit, most of the times you won't be interested in that output.. Again, I ask, whose damn fault is that?

P.S. Don't forget this isn't the first time this happened.. It's the most wide-spread because this time Linus answered them in public..

P.P.S. If I as a programmer, somehow create.. pff, let's say a PHP script that crashes the apache server.. Even if it's apaches problem, do you think it would be normal for me to leave my script as it is or fix it from my part too?

it is really easy to break the kernel
i broke it yesterday by playing with alsa
is it an alsa-s flaw that i am an idiot ?

to compensate for what i did would make alsa less efficient as it would have to check things a lot,
and what i did is very much bad practice
so should i report it ?

No, it is not.
At the time that bug was reported the bug in systemd that caused the spamming was already fixed in their git. All Kay Sievers had to do was to tell the bugreporter: "We fixed that already, please use a newer version" and marking that bug as fixed. Why he didn't is something I (and many other people) can't explain at all.

Which is indeed in both cases a very weird behavior and I can understand that people are upset about this. The obvious solution: Let someone capable of actually handling bugs and bugfixing in a sane way do the job, not a guy that doesn't seem to care at all, which in the end damages the image of the whole project.

I still think that there is nothing wrong with them using the generic debug term, so it would be more sane to use a namespaced option.
I think I already answered that: I expect both parties to get their act together and fix the bugs on their respective parts of the code.

The question is which part of the code is the cause for the breakage and how it is intended to be used. If a logger can crash the kernel by actually doing its job, logging, even if it is large amounts of logs, then this is clearly a bug.
If you broke Alsa by misconfiguration or by using it in a way that it not is intended to be used then this is not a bug, but may be interesting to look at nonetheless from a security point of view.

After all this I still can't understand why systemd even exists. Why would we need it?

5 members found this post helpful.

For a good time in F-land, get into XFCE, then unplug a usb device. That generated over 2100 lines of kernel fault messages and stack dumps. Fortunately, I didn't tell abrt kerneloops how to log into bugzilla.

The hplip developers are covering all bases. The slackware hplip package contains both /usr/lib/systemd/system/hplip-printer@.service and /usr/share/hal/fdi/preprobe/10osvendor/20-hplip-devices.fdi. Is that the way of the future where package developers have to include every possible system configuration? I was under the impression that the kernel was the kernal, providing the interface between user-land and the hardware; the OS was in the realm of the system administrator, which shell to install, which packages, to X or to console, etc. A computer is a tool, nothing more. Different people use different sets of tools in their work area. Chefs use pots, pans, ovens, salamanders, freezers, food, etc.; furniture makers use chisels, hammers, saws, routers, joiners etc.; fabricators use mills, press brakes, benders, welding equipment, lathes, band saws, etc. To build a system that includes all of that would be ludicrous. The customer chooses what they need, not the operating system packager. Linux is not Windoes. Why would I want a gui when a simple console session gets me into a cluster server where I can run weather simulations, stack thousands of layers of telescope images, calculate radio interferometry, calculate the moments and tensors of earthquakes, etc.? Tossing code at the screen in the hope that it turns into something useful is not the way of a computer scientist, who spends only 10% of a project coding, 90% planning, documenting, designing algorithms, etc. When I examine code with no overall documentation, descriptions of functions, sidebar comments for explaining subtleties and side effects, I gotta wonder why someone is shipping stuff that is incomplete? Folks who find flaws in Microsoft products have no access to the source code, yet they've been finding flaws and exploits for decades. A rare flaw in the source code of a Linux program gets reported to the chief software developer who either delegates or designs a patch that is pushed to public distribution the same day.

PS. I traced my scanner problem to sane-backends. An undocumented change moved my scanner backend from avision to genesys. I apologize for criticizing the usual suspects.

Hope Linus would remain strong in his attitude and advance kernel interests consistently. This is not just an episode of one systemd issue which was finally (after embarrassing publicity) fixed so everybody including kernel devs should shut up from now again. This is more than a minor technological detail. It's also a sociological and strategical situation many narrow minded nerds can hard to understand.
The linked G+ shows or rather complete the situation Linux is currently heading toward. RH as the most influential commercial subject tries to better monetize their investments and I don't intend to blame them here, but as a side effect it leads to hijacking of work of many volunteers and other non-by-RH paid developers into their own complete "Core/Base" OS and break compatibilities and conventions with system handling. One of the strategical bottlenecks between Linux and userland is the init system so the target is more than obvious. In addition as one of the greatest breadwinners has good breeding ground for enough apostles to push their interests without direct task assignments. Google managed so far with their Android just use Linux without attempts to take control over it.

It may come time to re-think licensing of future Linux code to be better protected before hijacking of non-community sphere and what consequences it may lead including reaction of upset companies profiting from Linux business.

What I don't understand is, in last 20 years no other application or developer has managed to spam the kernel by using the debug option along with their own userspace parameters?

Regards.

1 members found this post helpful.

Here's another interesting question: If systemd caused a kernel crash whenever someone used the "debug" kernel parameter, how come the systemd developers never noticed it? The only answer is that they never actually used that option. So much for testing.

To those who keep claiming this was somehow a kernel bug, here's a car analogy that works pretty well: The "debug" flag is the Linux kernel equivalent of starting your car engine with the hood open. You can't actually drive your car when it's in this "mode" (and no sane person would ever try), but it's very useful for "debugging" the engine.

Now, assume that the "hood is open" state can be detected over the CAN bus, and that the manufacturer of the stereo, sorry, "car entertainment system", decides to interpret this as a signal that the stereo should enter "debug mode" as well. In and by itself that's perfectly fine, and I'm sure the engine manufacturer would have no issues with it.

Unfortunately, the "debug mode" for the stereo system turns out to involve continuously outputting a 50 Hz signal at maximum volume, which not only drowns out the engine noise (which the mechanic needs to hear), but also quickly drains the battery since the engine is idling, ultimately causing the engine to stop.

I guess you could could blame the car manufacturer for insufficient soundproofing between the coupe and the engine compartment, or point out that a better regulator might have made it possible for the generator to power both the stereo and the ignition even with the engine idling and the stereo at full blast, but ...

5 members found this post helpful.

It was a bug and that bug is fixed. In the meantime it showed a flaw in the logging mechanism used in the kernel. This happened the first time in 20 years, indeed, but that doesn't make it less a bug.

I can only repeat myself here: The bug was noticed by systemd developers and fixed before that bug report was even issued. Now I could turn around and say "So much for reading up on the issue before commenting", but let us just assume that I won't do that, because to err is human.Sorry, but no, it does not.

In the meantime, can we not turn this into another "I don't like the design of systemd" thread? The topic here is not systemd itself, it is the behavior of a developer (which I by the way find unacceptable and which is a reason why I won't run systemd on any of my systems for other than experimental purposes).

1 members found this post helpful.