logrotate(8) and copytruncate as default

[Lennart Poettering]

On Fri, 28.06.13 01:17, Jan Kaluza (jkaluza at redhat.com) wrote:

> > > Why would you want this? I mean, we rate-limit per-service anyway, so
> > > the issue of one app flooding evreything else should be mostly
> > > non-existant. And hence, what you are asking for is some policy control
> > > about what to delete first, which only really matters if your disk space
> > > is very very limited?
> > 
> > Would you consider it sane to log say Apache traffic to the journal?  If
> > not, then there's still logrotate in the picture, and daemons need to do
> > the whole SIGHUP dance.  You can ignore the rest of this message in that
> > case.
> 
> I have httpd module for that, the problem is this bug:
> <https://bugzilla.redhat.com/show_bug.cgi?id=963620>. Once we fix this
> particular problem described in the bug, it will be possible to log
> structured httpd information into journal. Right now it's possible, but
> the performance is not good.
> 
> I think right now (and in the short-term/mid-term future) journald is
> not ready yet to fully replace classic log files as we know them for
> example from httpd, but I hope in some long-term future, it will be done.
> 
> There are clear benefits of journald logging I would like to have in
> httpd.

This is pretty much in-line with how we see it from upstream journald:
we want journald to scale well enough that it can just work HTTP logs
too.  Currently it doesn't (we spend too much time on collecting the
meta-data from /proc), but Jan and others have been working on kernel
patches to get this improved.

So, yeah, we are very interested in providing a building block for
others, and cover all major usecases, even if our particularly own one
is just system logs.

And on the topic of splitting up journal files: doing this makes sense
for access control reasons, and really only for that. Splitting things
up does not make sense for filtering (please use filtering while viewing
the files instead, it's more powerful, much more "live" and should be as
performant), and not really for enforcing data retention policies either
(for that we should probably repack the journals while dropping unwanted
stuff).

> > Sometimes I've thought it'd be nice if it was easy to spin up a
> > per-application journal daemon, with its own configuration and storage.
> > Perhaps optionally an admin could use journalctl to see a merged view
> > of these "extended service journals" with the system journal.

Our clear approach is to have a unified database and filter at display
time.

(Note that the reason why we have the per-uid split up mode is actually
a cloud setup, where UIDs map to customers, and each customer should get
access to his own service logs).

Lennart

-- 
Lennart Poettering - Red Hat, Inc.