Hacker News Reader

Comment by XorNot | Hacker News Reader

I can't speak to the first problem, but the second is more of "this is strange and I don't care to learn how it works".

journalctl --no-pager

Problem solved. I mean, you have the command, it's right there in the usage text. Which, awesomely, does invoke a pager when you do journalctl --help so if you're stuck on a 80x25 console (as you might be on a broken system) you can easily actually read the help options.

View on HN

I found that when the output is piped it doesn't invoke the pager. This seems reasonable to me.

What doesn't seem reasonable is the truncation behaviour. When the output isn't piped, it gets truncated to the width of my terminal. When the output is piped, it gets truncated to 80 columns. I'd expect no truncation when the output is not a terminal.

This is an outdated systemd though (I installed it on a Rasberry Pi [Raspbian] in order to play with it), so this may have changed.

>I found that when the output is piped it doesn't invoke the pager. This seems reasonable to me.

This might be less being smart and getting out of the way. From http://en.wikipedia.org/wiki/Less_%28Unix%29#Usage:

>By default, less displays the contents of the file to the standard output (one screen at a time). If the file name argument is omitted, it displays the contents from standard input (usually the output of another command through a pipe). If the output is redirected to anything other than a terminal, for example a pipe to another command, less behaves like cat.

That could be, but the change in wrapping behaviour makes me think it's journalctl doing it. If less acts like cat when the output is a pipe, then it wouldn't be wrapping at 80 columns, so journalctl must be doing the wrapping in that scenario.

    journalctl | cat

...would cause less to act like cat and cat to, well, :-), and then the tty driver usually wraps from the last column to the first.

Sorry, when I said "wrap" I should have said "truncate".

journalctl truncates at the width of my terminal or at 80 columns if the output is not to a terminal.

yum does the same thing. I actually looked at the code and it always assumes the output width is 80 characters and wraps or center…truncates if output isn't a terminal. It also doesn't properly sort its output, so you're tempted to use `yum search | sort`, which ends up with indented lines at the top of the output.

Of course, the recommended thing to do is use a different program for scripts/pipelines rather than yum, so now there are two different interfaces that need to be remembered. yum looks like a terminal-friendly program, but actually isn't.

https://bugzilla.redhat.com/show_bug.cgi?id=584525

https://bugzilla.redhat.com/show_bug.cgi?id=986740

> I can't speak to the first problem, but the second is more of "this is strange and I don't care to learn how it works".

I can't speak for you not speaking to the first problem, but the second is more of "this is strange and I didn't care to read the text"

> In the grand systemd tradition, there is no option to control this; all you can do is force journalctl to not use a pager or work out how to change things inside the pager to not do this.

(emphasis mine)

> Problem solved. I mean, you have the command, it's right there in the usage text. Which, awesomely, does invoke a pager when you do journalctl --help so if you're stuck on a 80x25 console (as you might be on a broken system) you can easily actually read the help options.

From reading the text, I'm under the impression that the issue is the mangling of $LESS. One would expect that $LESS is set up how the user wants it, if the user wants -S he'll set that.

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.

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.

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.

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/...

pager.c:59 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.

Thanks a lot for the explanation and I appreciate your direct pointers to the source.

Now, given that we both consider the $SYSTEMD_LESS and $LESS cascadation (? You get what I mean) a decent idea and seeing that you found the right spot to add it, even gave a ~diff~ in your comment here...

Have you considered reporting that as a bug or sending that as a patch?

Wouldn't it make sense to defer judgement ("another reason I don't consider systemd to be usable") until your patch is accepted or rejected?

ASK HN: When did using open sores software become so much like joining the Communist Party?

I think you and zaphar both have good points. That is to say, if for some reason you have $LESS set, it would be nice if journalctl respected it. (I'm trying not to take that and the kernel debug flag fiasco and view it as a trend.) However, as you say, if the only command you invoked was journalctl, it makes no sense to consult other documentation.

    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.

Yeah I'm afraid we have to agree to disagree here too. I'll just say that if you launch journalctl and see output that is obviously being printed to the screen by less my first thought will be to check my less configuration not journalctl's. These tools are meant to be used in a way that respects the users configurations for a reason.

Flouting that convention is bound to be rage inducing when encountered during a particularly nasty debugging session.

And this is why Torvalds defaults to "if a change in the kernel breaks user space, the fault is in the kernel no matter how buggy the user space is".

The attitude of many of the core systemd devs seems to be the polar opposite. They decree from on high, and if you don't like it thought luck.

In a sense this is the same difference in attitude we see between Apple (systemd) and Microsoft (Linux kernel).

Microsoft has in the past bent over backwards to ensure that people could run older software on newer version of Windows.

Apple in contrast have removed and changed expected product behaviors virtually over night.

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

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. <<

- 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

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.

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)

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.

>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...

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

"In the grand systemd tradition, there is no option to control this; all you can do is force journalctl to not use a pager or work out how to change things inside the pager to not do this."

He mentioned that. So, yes, it looks like he cared to learn how it works.

But apparently not enough to think to alias journalctl --no-pager, like is the advice for literally dozens of other Unix shell commands? Because colorized ls output is certainly not an "option" either in that sense.

Or..

       -a, --all
           Show all fields in full, even if they include unprintable characters
           or are very long.

       -f, --follow
           Show only the most recent journal entries, and continuously print
           new entries as they are appended to the journal.

(I'm talking about -a, copied the _following_ -f because that is what the author is trying to use here. It was right there..?)

Edit: Although I'm not sure if he's complaining about truncated fields or long lines. Hmm..

While I agree with your first paragraph,

> if you're stuck on a 80x25 console

What's wrong with `journalctl | less` in this case? The only command I use regularly which invokes a pager by default is `man`, and that seems like an actual special case.

Edit: FTR, I agree with your assessment in the first paragraph, but not the judgement I infer you passing. IMO, things should avoid being strange.

It can make sense to invoke a pager by default to avoid blowing the current terminal scrollback to smithereen if the user himself forgets it. Especially for diagnostic tools, where the information left in the scrollback buffer could be useful and not saved anywhere.

Fair point, I guess.

I very rarely work with a non-virtual terminal, but when I do I take a photo before typing anything. Perhaps that's only practical for me because it's pretty rare.

> The only command I use regularly which invokes a pager by default is `man`

Git also invokes a pager by default. And it also sets $LESS when doing so. In fact, it wouldn't surprise me if systemd's automatic use of a pager was based on git; IIRC, it used to set $LESS to the exact same value git used (I believe systemd has changed it since then).

I super dislike this btw. If I want a pager I'll use a pager. I'm using Git, I can handle `| less`.

I tested this just now: journalctl | less works normally for me on Ubuntu Utopic.

Wait, so the --no-pager does invoke the pager, but with different options? That would be surprising.

It looks to me like you either get a pager with broken settings, or you get no pager at all.

Reply on news.ycombinator.com