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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel