logrotate(8) and copytruncate as default

Zbigniew Jędrzejewski-Szmek zbyszek at in.waw.pl
Fri Jun 28 19:48:58 UTC 2013

On Fri, Jun 28, 2013 at 02:46:25PM -0400, Matthew Miller 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.
'uid' as default doesn't make sense, at least with the current way of accesing
logs. It is really nice to be able to view messages about a service
interleaved from various sources. Now when you say 'journalctl -u httpd',
you get logs from the processes in the httpd.service, but also messages
from systemd about this service, and possibly information about coredumps
and hopefully, soon, messages from setroubleshoot. With 'uid', and looking
only at one file, you'd get only the first kind.

With user messages the situation is better, because the messages from
"outside" are less interesting, so the "login" split works mostly ok.

Also, there's currently only one policy for rotation, so journald will
not treat logs for one service specially. It would be simple to add
a cron job which removes those files, but it is better to have such
functionality directly in journald.


More information about the devel mailing list