5 ms·

Linux Torvalds: [1] >> No, we very much expose /proc/cmdline for a reason. System services are supposed to parse it, because it gives a unified way for people t

Linux Torvalds: [1] >> No, we very much expose /proc/cmdline for a reason. System services are supposed to parse it, because it gives a unified way for people to pass in various flags. The kernel doesn't complain about flags it doesn't recognize, exactly because the kernel realizes that "hey, maybe this flag is for something else". <snip> And yes, that does include "quiet" and "debug". Parsing them and doing something sane with them is not a bug, it's a feature. << So - nothing to see here, seems okay - not related to the subthread at all anyway 1: http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01488.html http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01488.html

thwarted 12y ago
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.
digi_owl 12y ago
>doing something sane Dunno if dumping the output of every last damn command performed by systemd, and the daemons it starts, into dmesg can be considered sane...
- darklajid 12y ago
  I cannot follow. I think you meant kmsg - and where else would you stuff messages when the filesystem isn't there yet? I mean .. you have no / or /var yet, where do you send your log messages? The whole reason for the bug report this angry GP wanted to share with us is that there was a buggy, wrong assert filling up the logs and causing issues during boot. It was literally just a bug. People can now form a mob and complain that their favorite init system never exposed a bug like that.. That's not related to - logging to kmsg (that's okay, just don't kill it because you're doing stupid things) - parsing the 'debug' kernel command line flag, the original complaint of the GP

thwarted 12y ago

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.

digi_owl 12y ago

>doing something sane Dunno if dumping the output of every last damn command performed by systemd, and the daemons it starts, into dmesg can be considered sane...

darklajid 12y ago
I cannot follow. I think you meant kmsg - and where else would you stuff messages when the filesystem isn't there yet? I mean .. you have no / or /var yet, where do you send your log messages? The whole reason for the bug report this angry GP wanted to share with us is that there was a buggy, wrong assert filling up the logs and causing issues during boot. It was literally just a bug. People can now form a mob and complain that their favorite init system never exposed a bug like that.. That's not related to - logging to kmsg (that's okay, just don't kill it because you're doing stupid things) - parsing the 'debug' kernel command line flag, the original complaint of the GP