aha! I figured out why journalctl's auto-pager bugs me when git's doesn't (and possible solution)

Enrico Scholz enrico.scholz at informatik.tu-chemnitz.de
Fri Oct 19 09:39:51 UTC 2012

Adam Williamson <awilliam at redhat.com> writes:

>> >   - don't auto-page;
>> yes; that's the best solution.  The auto-pager is perhaps the most
>> annoying feature of systemd.  I have no problem in scrolling back some
>> pages in my terminal with shift-pgup, but having a status request block
>> (plain 'systemctl' or 'journalctl' request a status) is just broken.
> I don't really look at it that way. Let's see, how to put it...
> Okay, so with the old system, I don't recall *ever* doing 'cat
> /var/log/messages'.

It depends on the usecase. 'cat' is an option when system does not run for
a long time yet or the different message types are filtered (e.g. into
/var/log/secure). Else:

 tail -n200 /var/log/messages

and when I see that information are too difficulty structured to find
the wanted piece at the first glance:

<up> | less   --> perhaps '-S' within less

This workflow is not possible with journalctl anymore.

It might not be the most efficient way to do things, but the '<up> |
less' part works for a lot of other use cases too so that I do not have
to remember which options are required by program A and which by program
B to page the output.

Often, I know exactly what I want to do next after the 'tail -n200' (or
a 'chkconfig --list') and start typing the next command while screen is
filled with output.  This does not work with systemd anymore because
pager is entered.

> Did/do you usually less /var/log/messages? Or did you usually cat it?

fwiw, I develop for embedded systems (which are using systemd).  Showing
complete log with 'journalctl' (and SYSTEMD_PAGER=) (and formerly 'cat
/var/log/messages' or 'logread') is not uncommon in this usecase.

>> Or, do you want that e.g. the 'ls -l' output gets auto-paged?
> Thinking about this case, when I'm doing an ls -l which I know will be
> long, I usually wind up trying to order it in such a way that what I
> want to see will be at the bottom (classically, ls -ltr)...that doesn't
> really work with journals. How about you?

filters like 'll -tr' or 'll -Sr' are efficient and not uncommon, indeed.
But I use also the plain 'll' very often to get an overview.

But I never want 'll' to be auto-paged; regardless whether it displays 1
or 1000 lines.


More information about the devel mailing list