4 ms·

Yawn. It's been covered to death that the problem isn't that systemd was parsing the kernel command line, or that the kernel command line is exposed to user spa

Yawn. It's been covered to death that the problem isn't that systemd was parsing the kernel command line, or that the kernel command line is exposed to user space system services; the problem is the overloading of the string "debug", being parsed by two different things (the kernel and systemd), and systemd interpreting that in a way that made kernel debugging more difficult. Which is, in fact, mentioned generally in the very next paragraph that you failed to quote from that message: > But the problem appears when system services seem to think that they > *own* those flags, and nothing else matters, and they don't do > something "sane" any more. This is related to this subthread because the rest of the discussion on the mailing list around the kernel command line option systemd was parsing was asking for it to be named so as not to conflict, and there was pushback on adding that namespacing. And yet here we have a convoluted option naming override system (ignore $LESS, give hardcoded pager options to less, or use $SYSTEMD_LESS) which does feature namespacing. And too boot, it's a namespacing that undermines the exact case you define options in the LESS environment variable for.

darklajid 12y ago
You can yawn all you want. The link I posted says that 'overloading' (your word) the string 'debug' is fine. That's what it was meant for. I mean.. Go ahead, flame not just Lennart et al, Linus might be wrong too! Reading the mail I linked to leads to the following - userspace can and should read the kernel command line, very explicitly including the word 'debug' - userspace shouldn't crap out and cause a failure to boot. Surprise! The latter was a bug. The former is what you're trying to stuff into this thread for no reason. You might not like the 'kernel debug command line affects systemd' behavior, but that seems to be a) something the systemd guys want to keep (Ready your pitch fork..) and b) Linus himself seems to consider okay - IF that doesn't cause regressions. That whole mailing list thread is basically just about personal issues between Linus and Kay and a 'not my problem' attitude towards regressions. The general idea of using the 'debug' kernel command line parameter to mean something specific for systemd? That's considered okay and correct. So no, your whining is still unrelated to the (journalctl/less) topic at hand, you just felt that your pet peeve should be mentioned here as well. And .. it still makes no sense. There was a bug in systemd. It got fixed. Systemd reading/using kernel command lines without their own namespace? Fine. Correct. Good. Accepted. "debug" can mean a lot of things and everyone's entitled to use "debug" to mean something system specific. No need to invent a systemd.debug here. Straight from the horse's mouth, we're done. (For reference: You hijacked the thread with "(they) wouldn't namespace the kernel command line options so systemd's debug output isn't confused with the kernel's debug output" - and that's obviously wrong if you read the mail I linked to - and maybe a bit of the discussion around that)
- thwarted 12y ago
  You might not like the 'kernel debug command line affects systemd' behavior Correct, I don't like that behavior. Just like I, along with a bunch of other people, don't like this pager options handling. If I like it or not has nothing to do with what Linus says or what the systemd guys want to keep. I also find this namespacing of options to be inconsistent, either inconsistent with the rest of the systemd ecosystem and/or inconsistent with how environment variables are defacto-standard used to do things like this. I didn't "hijack" this thread. I made one comment, a snarky comment I felt was related. Usually my comments get ignored. But I guess not today. Glad I could keep you busy.

darklajid 12y ago

You can yawn all you want. The link I posted says that 'overloading' (your word) the string 'debug' is fine. That's what it was meant for. I mean.. Go ahead, flame not just Lennart et al, Linus might be wrong too! Reading the mail I linked to leads to the following - userspace can and should read the kernel command line, very explicitly including the word 'debug' - userspace shouldn't crap out and cause a failure to boot. Surprise! The latter was a bug. The former is what you're trying to stuff into this thread for no reason. You might not like the 'kernel debug command line affects systemd' behavior, but that seems to be a) something the systemd guys want to keep (Ready your pitch fork..) and b) Linus himself seems to consider okay - IF that doesn't cause regressions. That whole mailing list thread is basically just about personal issues between Linus and Kay and a 'not my problem' attitude towards regressions. The general idea of using the 'debug' kernel command line parameter to mean something specific for systemd? That's considered okay and correct. So no, your whining is still unrelated to the (journalctl/less) topic at hand, you just felt that your pet peeve should be mentioned here as well. And .. it still makes no sense. There was a bug in systemd. It got fixed. Systemd reading/using kernel command lines without their own namespace? Fine. Correct. Good. Accepted. "debug" can mean a lot of things and everyone's entitled to use "debug" to mean something system specific. No need to invent a systemd.debug here. Straight from the horse's mouth, we're done. (For reference: You hijacked the thread with "(they) wouldn't namespace the kernel command line options so systemd's debug output isn't confused with the kernel's debug output" - and that's obviously wrong if you read the mail I linked to - and maybe a bit of the discussion around that)

thwarted 12y ago
You might not like the 'kernel debug command line affects systemd' behavior Correct, I don't like that behavior. Just like I, along with a bunch of other people, don't like this pager options handling. If I like it or not has nothing to do with what Linus says or what the systemd guys want to keep. I also find this namespacing of options to be inconsistent, either inconsistent with the rest of the systemd ecosystem and/or inconsistent with how environment variables are defacto-standard used to do things like this. I didn't "hijack" this thread. I made one comment, a snarky comment I felt was related. Usually my comments get ignored. But I guess not today. Glad I could keep you busy.