F20 System Wide Change: No Default Syslog

[Lennart Poettering]

On Mon, 15.07.13 15:07, Martin Langhoff (martin.langhoff at gmail.com) wrote:

> On Mon, Jul 15, 2013 at 2:45 PM, Lennart Poettering
> <mzerqung at 0pointer.de> wrote:
> > You'd usually mount your journal files dir, then direct "journalctl -D
> > /path/to/the/journal/files/dir" to it. It will then collect all files in
> > that dir, interleave them and present them to you.
> 
> Thanks! And that -D would be to the dir normally under
> /var/log/journal AIUI.

Correct.

> My reference earlier to
> /var/lib/systemd/catalog was wrong I believe.

That's the message catalog, which is useful to augment log messages with
longer explanatory messages (accessible with journalctl -x). However, as
the texts in the message catalog are not stellar yet we don't advertise
it big time yet.

> =>>  - What guarantees of completeness/consistency  can we expect in
> >> practice from the journal in a hard poweroff situation? What is the
> >> price in terms of fsync() calls?
> >>
> > We sync() all journal files to disk 5min after each write the latest
> 
> that's new and interesting. AIUI pre-journal, the default was to
> sync() on every message for some logs (and overrriden with a hyphen
> for some logs). Am I wrong?

Yes, correct.

> Heading offtopic: Are there ways to control sync on a per-service
> basis? Or to trigger a sync on things like authentication failures,
> OOM shootouts, or kernel oopses?

No. this is currently not implemented, but certainly sounds like
worthwile additions. I think the best approach is to do this for log
messages with certain log levels and higher, and make that configurable,
and then simply make sure that OOM events and kernel oops set
approrpiately high log levels. Added to the TODO list.

> > Of course, things are different if some other form of corruption takes
> > place, i.e. where the fs gets corrupted so badly due to some external
> > condition that the middle of the journal files is bad. We do not provide
> > any recovery tools for that case currently.
> 
> It's gonna happen at some point :-) Anyway, if the file-format is
> append-only and indexes and such are rebuildable, then it's within
> reach.

Yes, writing such a tool should not be too difficult. We could even
extend the logic and from time to time write resynchronization tag into
the stream that is useful for resyncing access if the journal files get
corrupted somewhere in the front. (But this is harder than it sounds, as
we need to find a way to make sure that these tags cannot be part of the
normal payload, so that the resyncing logic cannot easily be confused.)

Note that the journal files are basically just a stream of
objects. There are objects that actually carry contents, and objects
that are just useful for indexing things. When recovering a corrupted
journal file it is sufficient to recover the former (and just skip over
the rest which is the majority), the indexing can be regenerated easily.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.