On Mon, Nov 18, 2013 at 07:31:21PM +0200, Joonas Sarajärvi wrote: > 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. Well the gui was mentioned in the thread, hence my mention. And as you see from later in my message, I have used journalctl, but unsuccessfully. I looked at the dependencies for journalctl, compared to less or cat, it is rather long. On a crashed system I wouldn't trust to have access to all these linked libraries. > > 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 helped, thank you! > 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. I looked at that. But was not clear what are valid values for the fields. Your and Tom's responses have given me enough pointers now to investigate more. > > Another useful parameter would be the --since parameter, e.g. like this: > journalctl --since 2013-11-15 _TRANSPORT=kernel This is also very helpful, thank you. Cheers, -- Suvayu Open source is the future. It sets us free. -- 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
