5 ms·

Okay, okay. I understand that the user might be surprised. man journalctl $SYSTEMD_LESS Override the default options passed to less ("FRSXMK").

Okay, okay. I understand that the user might be surprised. man journalctl $SYSTEMD_LESS Override the default options passed to less ("FRSXMK"). So - whereever the user defines $LESS I'd add a line a la export SYSTEMD_LESS=$LESS and that should solve the problem nicely, right? Surprising? Not intuitive? Maybe. But easily fixable with a quick peek at the man page.

zaphar 12y ago
So I have no dog in the systemd fight. However. $SYSTEMD_LESS is quite possibly one of the most aggressively stupid ways to force a bad UX on someone. I mean seriously. If you have $LESS defined then you obviously have an expectation that less will behave in a certain way. An expectation that has in all probability built up over years of tweaking your shell. For some other application to ignore that preference and in fact force it's own preference on you and only allow you to use your own preference for how less should work by reading not the docs for less but the docs for an unrelated application? That breaks so many rules it's just sad. Yes it's easily fixable with a quick peek at the man page for systemd which might not be the first thing you check given you've been using less for years. Systemd's manpage is the last thing I would check. First would be what is my $LESS set to? Second would be is less still less? At some point it would occur to me that maybe systemd is being aggresively stupid and check their manpage. But given I have no particular preference I would be inclined to assume it couldn't possibly be systemd's fault. I must have messed something up. Put this minor annoyance in the middle of attempting to debug a segfaulting init? That's what we call a major annoyance.
- darklajid 12y ago
  We got to agree to disagree here, I guess. I think it makes sense to use a pager by default. I am not convinced that your less options that were (granted, you referred to the full environment) 'tweaked over the years' necessarily apply. When you defined those options you were thinking of all the cases where you invoke less, or at least where you knew less was being invoked. Now journalctl defaults to use a pager if you invoke it. I'm not convinced that journalctl and less /var/log/messages should necessarily be configured the same. Maybe it would make sense to fall back to $LESS if $SYSTEMD_LESS isn't configured - I'm not sure - but I do think that it makes sense to have this environment variable. >For some other application to ignore that preference and in fact force it's own preference on you and only allow you to use your own preference for how less should work by reading not the docs for less but the docs for an unrelated application? That breaks so many rules it's just sad. Hmm.. Not in my world. The author was launching journalctl, not journalctl | less (which, as others have pointed out, would probably work as he expects it to). If you launch 'foo' and it doesn't do what you want and aren't an expert in all things 'foo', read man foo. Which, for foo=journalctl, spells out that - there is an option to stop truncating very long fields - there is an option to use no pager - the default pager is less - the default less configuration is as quoted above If you launch journalctl, see output you don't like and _don't_ skim the manual? Now that is what I personally would consider sad.
  - pdkl95 12y ago
    The need for separate configuration sounds contrived, breaks existing expected behavior, and assumes that this tool is special, unlike all of the other tools that call use a $PAGER. The comparison isn't "jornalctl" vs "less /var/log/messages". jornalctl should respect $PAGER (it does), and it should similarly respect any other environment variable the user sets. If there really was a need to override behavior of the pager for just this one tool, the normal solution should be to locally override these cases: alias journalctl="LESS='...opts...' journalctl" It is worth pointing out that this solution works for any tool that uses the $PAGER, and isn't specific to journalctl. If, for some strange reason that isn't an acceptable solution (such as Lennart's hatred of shell scripting - which he's entitled to, if that's the way he wants HIS environment to work), then a far better solution would be, as you suggest, two variables in priority order. It's a trivial change: [pager.c:92] - less_opts = getenv("SYSTEMD_LESS"); + less_opts = getenv("SYSTEMD_LESS") || getenv("LESS"); This makes no assumptions about what the user intended and accepts either their general or specific settings, if present. This IS done for the $SYSTEMD_PAGER / $PAGER at [pager.c:59] making it somewhat strange that similar behavior wasn't also used for $LESS. TL&DR: Setting defaults when $LESS isn't present is fine. Overriding behavior when a special, tool-specific request is also fine. Requiring everybody to search documentation and set a new environment variable to restore the standard, expected behavior is lazy and rude. I set $LESS (and $PAGER, and $EDITOR, $VISUAL, $LESSOPEN, ...) for a reason, and the value(s) change depending on what I'm working on[1]. Overriding these should never be done as default behavior, or it is creating extra work for no reason. Assuming you know WHY I override $LESS (or any other environment variable) is always bad behavior, because you cannot know what all possible requirements that everybody will have. // yet another reason I don't consider systemd to be usable pager.c:92 http://cgit.freedesktop.org/systemd/systemd-stable/tree/src/shared/pager.c?h=v217-stable#n92 http://cgit.freedesktop.org/systemd/systemd-stable/tree/src/... pager.c:59 http://cgit.freedesktop.org/systemd/systemd-stable/tree/src/shared/pager.c?h=v217-stable#n59 http://cgit.freedesktop.org/systemd/systemd-stable/tree/src/... [1] I use custom tool that can push/pop environment variable overlays, which setup use/project specific behavior for a lot of stuff... including the pager.
    - darklajid 12y ago
thwarted 12y ago
Oh, they'll namespace the pager options environment variable, but wouldn't namespace the kernel command line options so systemd's debug output isn't confused with the kernel's debug output? This is some next level inconsistent shit. https://bugs.freedesktop.org/show_bug.cgi?id=76935 https://bugs.freedesktop.org/show_bug.cgi?id=76935
- darklajid 12y ago
  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.

zaphar 12y ago

So I have no dog in the systemd fight. However. $SYSTEMD_LESS is quite possibly one of the most aggressively stupid ways to force a bad UX on someone. I mean seriously. If you have $LESS defined then you obviously have an expectation that less will behave in a certain way. An expectation that has in all probability built up over years of tweaking your shell. For some other application to ignore that preference and in fact force it's own preference on you and only allow you to use your own preference for how less should work by reading not the docs for less but the docs for an unrelated application? That breaks so many rules it's just sad. Yes it's easily fixable with a quick peek at the man page for systemd which might not be the first thing you check given you've been using less for years. Systemd's manpage is the last thing I would check. First would be what is my $LESS set to? Second would be is less still less? At some point it would occur to me that maybe systemd is being aggresively stupid and check their manpage. But given I have no particular preference I would be inclined to assume it couldn't possibly be systemd's fault. I must have messed something up. Put this minor annoyance in the middle of attempting to debug a segfaulting init? That's what we call a major annoyance.

darklajid 12y ago
We got to agree to disagree here, I guess. I think it makes sense to use a pager by default. I am not convinced that your less options that were (granted, you referred to the full environment) 'tweaked over the years' necessarily apply. When you defined those options you were thinking of all the cases where you invoke less, or at least where you knew less was being invoked. Now journalctl defaults to use a pager if you invoke it. I'm not convinced that journalctl and less /var/log/messages should necessarily be configured the same. Maybe it would make sense to fall back to $LESS if $SYSTEMD_LESS isn't configured - I'm not sure - but I do think that it makes sense to have this environment variable. >For some other application to ignore that preference and in fact force it's own preference on you and only allow you to use your own preference for how less should work by reading not the docs for less but the docs for an unrelated application? That breaks so many rules it's just sad. Hmm.. Not in my world. The author was launching journalctl, not journalctl | less (which, as others have pointed out, would probably work as he expects it to). If you launch 'foo' and it doesn't do what you want and aren't an expert in all things 'foo', read man foo. Which, for foo=journalctl, spells out that - there is an option to stop truncating very long fields - there is an option to use no pager - the default pager is less - the default less configuration is as quoted above If you launch journalctl, see output you don't like and _don't_ skim the manual? Now that is what I personally would consider sad.
- pdkl95 12y ago
  The need for separate configuration sounds contrived, breaks existing expected behavior, and assumes that this tool is special, unlike all of the other tools that call use a $PAGER. The comparison isn't "jornalctl" vs "less /var/log/messages". jornalctl should respect $PAGER (it does), and it should similarly respect any other environment variable the user sets. If there really was a need to override behavior of the pager for just this one tool, the normal solution should be to locally override these cases: alias journalctl="LESS='...opts...' journalctl" It is worth pointing out that this solution works for any tool that uses the $PAGER, and isn't specific to journalctl. If, for some strange reason that isn't an acceptable solution (such as Lennart's hatred of shell scripting - which he's entitled to, if that's the way he wants HIS environment to work), then a far better solution would be, as you suggest, two variables in priority order. It's a trivial change: [pager.c:92] - less_opts = getenv("SYSTEMD_LESS"); + less_opts = getenv("SYSTEMD_LESS") || getenv("LESS"); This makes no assumptions about what the user intended and accepts either their general or specific settings, if present. This IS done for the $SYSTEMD_PAGER / $PAGER at [pager.c:59] making it somewhat strange that similar behavior wasn't also used for $LESS. TL&DR: Setting defaults when $LESS isn't present is fine. Overriding behavior when a special, tool-specific request is also fine. Requiring everybody to search documentation and set a new environment variable to restore the standard, expected behavior is lazy and rude. I set $LESS (and $PAGER, and $EDITOR, $VISUAL, $LESSOPEN, ...) for a reason, and the value(s) change depending on what I'm working on[1]. Overriding these should never be done as default behavior, or it is creating extra work for no reason. Assuming you know WHY I override $LESS (or any other environment variable) is always bad behavior, because you cannot know what all possible requirements that everybody will have. // yet another reason I don't consider systemd to be usable pager.c:92 http://cgit.freedesktop.org/systemd/systemd-stable/tree/src/shared/pager.c?h=v217-stable#n92 http://cgit.freedesktop.org/systemd/systemd-stable/tree/src/... pager.c:59 http://cgit.freedesktop.org/systemd/systemd-stable/tree/src/shared/pager.c?h=v217-stable#n59 http://cgit.freedesktop.org/systemd/systemd-stable/tree/src/... [1] I use custom tool that can push/pop environment variable overlays, which setup use/project specific behavior for a lot of stuff... including the pager.
  - darklajid 12y ago

thwarted 12y ago

Oh, they'll namespace the pager options environment variable, but wouldn't namespace the kernel command line options so systemd's debug output isn't confused with the kernel's debug output? This is some next level inconsistent shit. https://bugs.freedesktop.org/show_bug.cgi?id=76935 https://bugs.freedesktop.org/show_bug.cgi?id=76935

darklajid 12y ago
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.