[darkarmani]

Wow. This comment captures it best:

> "Hmm, a user adds to the kernel command line "debug" and systemd starts spitting out so much crap that the system doesn't boot anymore? That sounds like a major regression to me. Note this is a kernel command line, not a systemd command line. Userspace tools should not be using the same kernel parameters that are defined by the kernel. That's just broken and wrong.

> This bugzilla is the poster child of why people hate systemd and do not trust the developers that work on it."

[shawnz]

> Userspace tools should not be using the same kernel parameters that are defined by the kernel. That's just broken and wrong.

My understanding is that this is not the issue and, in fact, the command line parameters are provided to userspace in the way that they are exactly so that applications can do this kind of thing.

Rather, the real issue is that the flag IS commonly used this way, and systemd's response to it being set was so aggressive that it prevented it from being used for anything else. A not-uncommonly-used system configuration, having "debug" set, was being broken unnecessarily and in an unintuitive way.

[darkarmani]

Yes. Linus explains that the kernel will ignore flags it doesn't know for that reason; however, systemd should not be doing anything with the debug flag as that is meant for the kernel. The systemd flag should be namespaced.

[shawnz]

I believe we are both referring to this post: http://permalink.gmane.org/gmane.linux.kernel/1677099

In it, Linus says the following:

> No, we very much expose /proc/cmdline for a reason. System services are supposed to parse it [...] And yes, that does include "quiet" and "debug". Parsing them and doing something sane with them is not a bug, it's a feature.

[programmer_dude]

I think as always the kernel should be made robust enough (in this case through rate limiting) to handle such abuse.

In a way this Sievers guy is right but he could have been more polite in asking the kernel devs for this feature. And he needs to co-operate by cutting down the log traffic until the kernel is fixed.

[Rantenki]

While it would be nice for the kernel to handle any kind of bad behaviour by default, it isn't always realistic.

I mean, it would be nice if the kernel by default could handle a simple forkbomb, but it doesn't without restricting your limits.conf fairly severely. You can blow up the system in a variety of ways that are outside of the kernel's responsibility. It's not up to the kernel devs to hack around your bad behaviour.

[programmer_dude]

Please see my response to tdsamardzhiev. I have replied to some of your points there. I agree this borders on bad behaviour since the author knows the kernel does not have rate limiting in place. Ideally he should have put in a feature request with the kernel devs and should have self regulated the log traffic using some workaround (like checking for debug.systemd) until the kernel stepped up its game. If I were Linus I would have taken this up as a challenge (as I am sure he will too).

[MBCook]

If you read through the kernel thread, it seems that's exactly what they're doing.

While systemd is obviously doing something stupid, no userspace program should be able to dump so much to the log that the machine becomes unusable. It seems like they were going to apply per-file descriptor limiting the way to they seem to limit in kernel logs on a per-log site basis.

[tdsamardzhiev]

I disagree - it's not the kernel's job to prevent user-space programs from doing stupid stuff.

[programmer_dude]

I think it is. It is the kernel's job to protect itself from user-space mischief. It always has been. For example why are processes isolated from each other? Why does it guard against invalid memory/resource accesses etc? The kernel should be able to protect itself from denial of service attacks and must remain functional at all costs. A fork bomb is equally bad it is no excuse for the current failure mode.

BTW Linus agrees rate limiting is desirable here. This is the reason why I said systemd has to hold off its fire hose until the kernel can take care of it.

[rsanders]

The kernel does quite a lot of work to prevent user-space programs from doing stupid stuff to each other, or to at least ameliorate the impact of such stupidity. One of the Unix philosophies has always been to prevent a runaway program from rendering the system inoperable.

systemd has apparently elevated itself somewhat above the typical "user space" level, but it's still not a bad idea to harden the interface between systemd and the kernel where possible.

[jlgaddis]

> ... the command line parameters are provided to userspace in the way that they are exactly so that applications can do this kind of thing.

Yes, and they should be using, e.g., systemd.debug just like they use other systemd.* parameters to avoid collisions (and shit like this).