logrotate(8) and copytruncate as default

[Jan Kaluza]

----- Original Message -----
> On Thu, 2013-06-27 at 23:38 +0200, Lennart Poettering 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.

> But if you do, then it would seem fairly sane to me on a medium traffic
> site to want the ability to have different retention
> policies for the webserver logs versus other system events like sudo
> activations or a change of the root password.
>
> I guess more broadly, one question that isn't fully clear to me is where
> to draw the line for system applications in general for use of the
> journal compared to per-application log files.  Like, were something
> like Koji running on a journal-enabled system, should it write all those
> build logs to the journal?  I'd say pretty clearly not...but where is
> the line?

Those are good points and questions I'm interested in too.
 
> 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.

I think this could be useful. It all depends if journald is intended to
replace classic log files. If it is, we probably really want to do
what you are suggesting here.

> 
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

Jan Kaluza