F20 System Wide Change: No Default Syslog

[Till Maas]

On Tue, Jul 16, 2013 at 04:21:43PM +0200, Lennart Poettering wrote:
> On Tue, 16.07.13 14:41, Till Maas (opensource at till.name) wrote:
> 
> > On Tue, Jul 16, 2013 at 01:25:54PM +0200, Lennart Poettering wrote:
> > 
> > > I am pretty sure that is just a misunderstanding. Note that journald
> > > (i.e. the *server* side) will immediately move away (i.e. "rotate") all
> > > journal files that it finds have not been set to "offline" when it
> > > starts up before writing, in order to make sure that it will not
> > > interfere with journal files that are incompletely written (possibly
> > > further corrupting them). However journalctl (i.e. the *client* side)
> > > will still access the file, and interleave it with all others it finds,
> > > and show it to you as far as that's possible.
> > > 
> > > So yeah, you could say that journald will 'ignore' the file. But
> > > journalctl won't, it will show them to you. And that's *good* that
> > > way. That's how it *should* be.
> > 
> > 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.

> 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?

Regards
Till