replacing rsyslogd in minimal with journald [was Re: systemd requires HTTP server and serves QR codes]

Lennart Poettering mzerqung at 0pointer.de
Wed Oct 10 18:36:52 UTC 2012


On Wed, 10.10.12 10:12, Richard W.M. Jones (rjones at redhat.com) wrote:

> On Wed, Oct 10, 2012 at 09:54:28AM +0100, Richard W.M. Jones wrote:
> > On Wed, Oct 10, 2012 at 09:50:43AM +0200, Björn Persson wrote:
> > > Lennart Poettering wrote:
> > > > On Tue, 09.10.12 09:09, Chris Adams (cmadams at hiwaay.net) wrote:
> > > > > How do you read this log when the system is not running (e.g.
> > > > > mounting filesystems of a drive on another system, running from a
> > > > > rescue image, etc.)?
> > > > 
> > > > journalctl -D <pathtothejournalfiles>
> > > 
> > > So the rescue system (which might not always be Fedora) must have 
> > > journalctl installed. Is the file format stable, or can it break if the 
> > > rescue system has a different version of journalctl? Is the format 
> > > perchance even documented so that other tools for reading logs could be 
> > > written?
> > 
> > This would be essential for libguestfs tools to parse logs out of
> > guests (we do it now by reading /var/log/messages etc which has all of
> > the properties you state).
> 
> I checked out the code, and it does seem as if the format is intended
> to be backwards compatible.  It uses a set of filesystem-like
> "compatible" and "incompatible" flags, so presumably a sufficiently
> recent journalctl would be able to read any previous version of the
> binary file format.
> 
> It would be nice to have this confirmed, and indeed enshrined in the
> policy of the journal, because it is IMHO essential that the binary
> log files will always be readable.

Yes, the compatible and incompatible flag bit fields are precisely to
provide good compatibility as the format evolves.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the devel mailing list