2013/11/18 Suvayu Ali <fatkasuvayu+linux@xxxxxxxxx>: > 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 -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
