Red Hat Bugzilla – Bug 109633
Handling of uniquely-named traces.
Last modified: 2015-01-07 19:06:53 EST
I have several apps that output uniquely-named traces/logs in a log dir (name unicity is achieved adding PID, start date or a sequence number to the file name). Once the trace/logs are generated they won't change ever. logrotate fails miserably when handled this kind of files. It rotates them once, then stops. (or else you tell it to create a new empty file on rotation and rotate on empty files and after some time you fill your disks with empty files or even non-empty files if you use compression). There seems to be no easy way to tell logrotate to : 1. rotate unconditionnaly traces 2. remove them after a few rotations/time and forget they ever existed. Or am I missing something ?
I don't think logrotate is meant to handle these type of situations. The tmpwatch utility might be better suited - it can delete files after they are a certain number of days old.
tmpwatch won't do compression like logwatch... . Consider it a rfe then. From a technical POV this might be different, from an admin/user POV handling all sorts of traces/logs in the same files is a must.
(for example some apps use combined cross-referenced logs and traces. So right now you have to use one logrotate file, another for tmpwarch and yet another for the compression. And be sure all of them match at all times, since the stuff is cross referenced. This is an admin's nightmare)
I don't want to let this report sit here and pretend that anything is going to happen with it. A patch would be harder to argue with, but it's not likely that I'll ever make time to code the feature, given other priorities.
That's fair if not exactly welcome