Bug 867841 - RFE: journalctl pager should default to end of file, not start
RFE: journalctl pager should default to end of file, not start
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-18 08:07 EDT by Matthew Miller
Modified: 2013-05-15 23:00 EDT (History)
11 users (show)

See Also:
Fixed In Version: systemd-201-2.fc18.6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-05-15 23:00:59 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthew Miller 2012-10-18 08:07:24 EDT
I figured out why I had such a strong frustration with journalctl using a pager by default. In short, it's because of the type of data presented and the reason I'm looking at it in the first place.

Other utilities which have been given as examples that automatically use a pager are "man" and "git". That's true, but there's important differences in *what* is being presented.

Man is a document reader. When you run it, you start at the top and read
down. A pager is natural; on ancient Unixes where it didn't page by default, one almost always did `man whatever|more`.

Git isn't a document reader, but when it presents time-based data, as in `git log`, it sorts by _reverse time_. That means the most immediately-relevant information is at the top of the page — one scrolls down to see older entries, or quits the pager.

But the log information from journalctl is in forward chronological order. Usually when looking at the logs, the more recent events are of most interest. So, every time I run journalctl, I have to take the extra step of scrolling to the bottom (with `G`, `>`, or `End` in less). That's not gigantic, but it adds up over and over. (And every time it happens, there's this message: this tool is not designed for what you're doing.)

If instead journalctl spit out to the terminal directly, it'd all scroll past, and I could  use my terminal's buffer to scroll back, or command-line tools to filter or sort the entries. Or I could choose to use a pager if that seems best. (All without extra key-strokes.) This is similar to what one does with a long `ls` listing.

So, possible solutions:

  - Reverse-sort the log entries, a la `git log`. (I don't think anyone
    really wants this. But it might be a reasonable command-line option.)

  - don't auto-page; enable that with a flag (I know Lennart does not
    like this; okay, fair enough.)

  - change the default less options to include +G, which jumps to the
    end of the file. (I'd also suggest adding the -M option to show
    line numbers -- it's nice, and makes it more clear that scrolling
    up is an option.)

So, specifically, my recommendation is to add '+G -M' to the less environment variables when calling journalctl.
Comment 1 Matthew Miller 2012-10-18 08:11:45 EDT
Possibly also -e, to make it exit automatically the second time you hit eof, but I'm not sure about that.
Comment 2 Matthew Miller 2012-10-18 08:17:45 EDT
Also: as of man-db 2.6.0 (9 April 2011), the default prompt for 'man' includes 
the string "(press h for help or q to quit)". Rather than using -M, we could (and probably should) construct a helpful custom prompt (including both quick help and useful journalctl information).
Comment 3 Lennart Poettering 2012-10-18 10:37:41 EDT
The problem with jumping to the end right-away is simply that the dataset might be huge and to seek to the end journalctl would have to send the full set of serialized logs to less first, and that simply doesn't scale.

If you have a huge journal (or any other file) and press "G" in less, then this is already slow, but the admin at least triggered it knowingly. But being "slow by default" is not a good idea I think.

"journalctl" is like "less /var/log/messages": you get a potentially huge file that might be expensive to jump around to the end.

Not sure what we could do about this: Educate people that "journalctl -n" or "journalctl -b" are awesome too? Implicitly add a "--since=today" or so if nothing is specified?

Of course on traditional syslog the problem was never this visible, since you only looked at one log file at a tie, and those where short due to rotation. But in the journal we tend to work on the full database, so this does become a bigger issue. An implicit "--since=-3day" might come close to the old behaviour, but not sure how I like that...
Comment 4 Michal Schmidt 2012-10-18 11:25:16 EDT
(In reply to comment #3)
> An implicit "--since=-3day" might come close to
> the old behaviour, but not sure how I like that...

Such a default is fine as long as there's an easy way to disable the limit. These come to mind:
 --since=''
 --since=0
 --since=bigbang

Not to miss an opportunity for bikeshedding: I would like the default to be a whole week (-7d).
Comment 5 Matthew Miller 2012-10-18 11:59:57 EDT
(In reply to comment #3)
> The problem with jumping to the end right-away is simply that the dataset
> might be huge and to seek to the end journalctl would have to send the full
> set of serialized logs to less first, and that simply doesn't scale.

This all really argues for reverse ordering. But that might make people's brains explode.

It's too bad less doesn't have an "upside down" mode where it reverses the input, starts at the end and loads more data as one scrolls up. If it did, journalctl could default to serializing in reverse order, and then the upside down mode would invert again, presenting it in chronological order but starting from the end. But. Not constructive line of thought since less doesn't do that. :)


> Not sure what we could do about this: Educate people that "journalctl -n" or
> "journalctl -b" are awesome too? Implicitly add a "--since=today" or so if
> nothing is specified?

journalctl -n is only useful in certain special cases. Time could vary between months (or years, but probably not on Fedora) or just minutes. Making some reasonable period the default sounds okay, since we now have the time-selection command-line options. (Is there a "--since=forever"?) The less prompt could even show what the time period is, making it clear.
Comment 6 Michal Schmidt 2012-10-19 08:16:00 EDT
(In reply to comment #5)
> It's too bad less doesn't have an "upside down" mode where it reverses the
> input, starts at the end and loads more data as one scrolls up. If it did,
> journalctl could default to serializing in reverse order, and then the
> upside down mode would invert again, presenting it in chronological order
> but starting from the end. But. Not constructive line of thought since less
> doesn't do that. :)

It's not that crazy, actually. I filed this RFE for less as bug 868284.
Comment 7 Lennart Poettering 2013-03-07 15:20:03 EST
We now have "systemctl -e" for jumping to the end of the file in git.

"journactl -be" and "journalctl --since=today -e" are your new friends.

I doubt we really can make this logic the default, because it might be slow if there are a lot of journal messages generated.

We also have "journalctl -r" for reversing the entries. I guess it's enough to consider this bug done.
Comment 8 Fedora Update System 2013-04-10 16:16:17 EDT
systemd-201-2.fc18.1 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/systemd-201-2.fc18.1
Comment 9 Fedora Update System 2013-04-11 19:29:26 EDT
Package systemd-201-2.fc18.2:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.2'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.2
then log in and leave karma (feedback).
Comment 10 Fedora Update System 2013-04-15 20:04:05 EDT
Package systemd-201-2.fc18.4:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.4'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.4
then log in and leave karma (feedback).
Comment 11 Fedora Update System 2013-04-17 22:41:43 EDT
Package systemd-201-2.fc18.5:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.5'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.5
then log in and leave karma (feedback).
Comment 12 Fedora Update System 2013-05-07 09:43:43 EDT
systemd-201-2.fc18.6 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.6
Comment 13 Fedora Update System 2013-05-09 06:05:09 EDT
Package systemd-201-2.fc18.6:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.6'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.6
then log in and leave karma (feedback).
Comment 14 Fedora Update System 2013-05-15 23:00:59 EDT
systemd-201-2.fc18.6 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.