Bug 867841
| Summary: | RFE: journalctl pager should default to end of file, not start | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Matthew Miller <mattdm> |
| Component: | systemd | Assignee: | systemd-maint |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | gholms, johannbg, lnykryn, metherid, mschmidt, msekleta, notting, plautrba, psplicha, systemd-maint, vpavlin |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | systemd-201-2.fc18.6 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-05-16 03:00:59 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Possibly also -e, to make it exit automatically the second time you hit eof, but I'm not sure about that. 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). 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... (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). (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. (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. 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. systemd-201-2.fc18.1 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/systemd-201-2.fc18.1 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). 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). 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). 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 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). 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. |
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.