logrotate(8) and copytruncate as default

[Colin Walters]

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.

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?  

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.