F20 System Wide Change: No Default Syslog

Lennart Poettering mzerqung at 0pointer.de
Tue Jul 16 16:09:32 UTC 2013

On Tue, 16.07.13 17:57, Till Maas (opensource at till.name) wrote:

> > > Will journalctl also mention that there is a broken jorunal file? Does
> > > it support to "fsck" the journal or to show the not properly referenced
> > > data to the admin?
> > 
> > journalctl will not show you that, but libraries do see this. The reason
> > we don't show this in journalctl is that when you "live" follow the
> > output of a journal being written then the file frequently has
> > half-written entries, which however will quickly be corrected as the
> > entry is completed.
> But in case journald decided to rotate a journal because it is not clean
> now new entries are to be expected there. Therefore journalctl should
> know that the journal is broken.

journalctl actually has an inotify watch on the journal dir. It will
notice when a file is rotated and will immeidately add the new journal
file that has been created as replaced to the files it watches and
interleaves. This is all hidden inside the library btw, to ensure that
clients do not need to be aware of rotation or anything and always see
the full set of logs, regardless what is currently going on.

> > There's "journalctl --verify" whose main purpose is to verify FSS
> > seals. It will also check the integraty of the data structures in a
> > journal however.
> What can be done if the verification fails? How can one get the
> incomplete data in case journald rotated a journal?

The tool will tell you how much of the file could be verified, starting
from the beginning. 

For tail corruptions your normal journalctl tool will provide you with
as much information as is possible to salvage from the file. It will
output the last complete log line and then finish. This is pretty close
to how good you can get.

Things are different for corruptions in the middle. We have no nice tool
for salvaging data from such corruption, but they could be written
relatively easily. However, since they are highly unlikely due to the
"append-only" model of the journal this hasn't been on our TODO list.


Lennart Poettering - Red Hat, Inc.

More information about the devel mailing list