logrotate(8) and copytruncate as default

[Lennart Poettering]

On Fri, 28.06.13 14:46, Matthew Miller (mattdm at fedoraproject.org) wrote:

> On Fri, Jun 28, 2013 at 07:27:30PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
> > Splitting is controlled by SplitMode=
> >   Controls whether to split up journal files per user. One of "login",
> >   "uid" and "none". If "login" each logged in user will get his own
> >   journal files, but systemd user IDs will log into the system
> >   journal. If "uid" any user ID will get his own journal files
> >   regardless whether it belongs to a system service or refers to a
> >   real logged in user. If "none" journal files are not split up
> >   per-user and all messages are stored in the single system journal. [1]
> > I guess this could be sanely extended to split the logs for some services
> > out even more.
> 
> Maybe we should make uid the default? What are the drawbacks? It seems like
> this would allow sysadmins the ability to do some more flexible things with
> log access without much effort.

No. The theory behind the journal is to have everything in one place, in
one centralized, comprehensive dataset, and then apply filters on it
*when reading it* to see just the bits of it you are interested in. We
made an exception to this only for login users, so that we can just
reuse normal Unix file system access controls to give them access to
their own files without giving them access to anything else.

There is no benefit on its own in splitting things up, that simply makes
things slower (as the complexity of interleaving journal files grows
O(n) with n being the number of journal files) and bigger (as within
unit files the same message fields are only stored once and henceforth
referenced just by their offset, the effect of which becomes nil if you
start anew too often).

To make this clear: the journal is *not* supposed to do everything
possibly anybody could ever think about. No. It's supposed to just work,
make the best of its situation and have only limited knobs to change,
for the stuff that really makes sense in major usecases. For
everything else you have rsyslog and ElasticSearch and whatnot. They
embed programming languages in their configuration files and that's OK
for them. For journald its not.

We will not split up journal files just for the sake of splitting them
up. We care about usecases. And stuff like "do some more flexible
things" is not a usecase.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.