Re: How avoid unwanted systemd-journald?
2013/11/18 Suvayu Ali <fatkasuvayu+linux(a)gmail.com>:
Hi Jonas,
I have a comment, and a question.
On Sun, Nov 17, 2013 at 03:46:55PM +0200, Joonas Sarajärvi wrote:
> The journald log format is documented at least to some extent [1], and
> there exists free software for reading the log. To me, it sounds like
> way more accessible than if it was a binary data format of a typical
> proprietary tool. For example, booting any Fedora live image should
> suffice if you need to read the journal of a system that uses journald
> and happens to become unbootable.
I am sure you (and everyone else on the list) will agree, tools for
viewing plain text (cat, more, less, <favourite editor>) outnumber and
are available on every platform compared to any specialised tool. Even
if a format is open, it still needs tools that support it. I would not
count on having a gui when my system crashes. Sometimes the only access
you have to a crashed system is the recovery prompt.
I wonder where this notion
that you'd need a GUI to access the journal
content came from. You do need a working journalctl, but it is not a
GUI tool. Normally it outputs syslog-like output that you could feed
to your favourite syslog-output-expecting log analysis tool.
> At least for my needs, the journal has been way more convenient
to use
> than rsyslog. It is much nicer to read logs when journalctl e.g.
> combines the older rotated logs with the latest ones. Also, it easily
> allows me to easily specify that I want just the logs of this month or
> of just this one boot, or of just some specific service.
I have been very frustrated with journalctl. The manual page is very
unhelpful in that regard. For example the other day, I wanted to
investigate why my laptop shutdown suddenly (I think it was
overheating), but there was no reasonable way for me to filter the cpu
specific messages. Could you give some pointers how I can do that? I
would be very grateful.
I am not sure where that message in particular would show
up. My first
instinct in such a situation would be to just run journalctl without
arguments. If the output is not piped anywhere, journalctl opens less
and puts the syslog-like output there. Now it is pretty same as if I
had run less /var/log/messages in a system that uses a traditional
syslog. I can for example press / to access the search function of
less and search for the "cpu" string.
Since a hardware related error would likely be logged by the kernel, I
might invoke journalctl like this:
journalctl _TRANSPORT=kernel
This would limit the things I get so that only kernel debug messages
are shown. Different filter criteria you could use are described in
the systemd.journal-fields man page.
Another useful parameter would be the --since parameter, e.g. like this:
journalctl --since 2013-11-15 _TRANSPORT=kernel
Now journalctl would omit old stuff that likely would not be
interesting in this case.
But maybe the message is not in the kernel log, and you'd wish to use
grep to search for the message like you could with a text-based
syslog? You can like this:
journalctl --since 2013-11-15 | grep -i cpu
The --since parameter is still useful, in case you happen to have many
months of log data stored in the journal. With the --since and --until
parameters, you can limit the search to any arbitrary interval that is
covered by your stored log data, regardless of how those times relate
to the times at which log rotation has happened.
Hopefully this helps. At least you should know that you can still use
your knowledge of the traditional unixy text-processing tools.
-Joonas