Logrotating single-issue files

[Keith Lofstrom]

Nicolas Mailhot writes:

>   I'm battling with a few apps that create uniquely-named traces/logs in
> a logdir (typically using PID / date or a sequence number as a unique
> identifier). I naively though it might be possible to use logrotate to
> compress old traces and remove them after a while.

...

>   Anyone got an idea ? Is the modified SuSE logrotate some people have
> been talking about able to cope with this ?

The SUSE modified logrotate takes an original and appends one date extension
(YYYYMMDD) then tosses it after a while.  Not what you are dealing with.

Logrotate is probably not the proper tool.  You may be able to use a pair
of "find ... exec ..." commands in a shell script called by cron to do
what you want.  While you might build some ugly scripts and call them
from logrotate, the next maintainer will have no idea where the behavior
is coming from - logrotate is expected to do only certain things.  


For example:
-----------------------------------------------------------------
#!/bin/bash
# /etc/cron.daily/myapp-log-maintainer

# compress all unused myapp log files of type A older than 2 days
find -atime 48 /var/log/myapp/logA* -exec gzip '{}' ';'

# delete all unused myapp log files of type A older than 2 weeks 
# (plus the above 2 days)
find -atime 336 /var/log/myapp/logA*gz -exec rm -f '{}' ';'

#all done
exit 0
-----------------------------------------------------------------

This is untested, and I often get the -exec part wrong, use at your
own risk.  I also tend to code the file paths as variables (for example,
MYAPPLOG=/var/log/myapp) and give full paths for executables in my own
shell scripts so I do not have to rely on possibly hacked PATHs, so 
the example script should probably be modified those ways.  You should
also put a README in the log/myapp directory telling future maintainers 
what the heck is going on.  You probably also want to log the fact
that this script was run in /var/log/messages.

You probably do not want to compress right away (hence the -atime).  You
might actually be running the app making the log when cron starts up.
But you may be happy with "-atime 1" or something, where the log file
can get compressed only an hour after you stop actively looking at it.
Remember, you may still be running myapp when this script runs.

Lastly, if you have a nightly backup procedure called by cron.daily, you
probably want to call this first.  And if you are using an rsync-based
disk backup procedure like I am, you do not want to modify the files at
all, or it causes just another copy (albeit compressed) to happen.  Just
delete them when they get old to keep your directories uncluttered.

Keith

-- 
Keith Lofstrom           keithl at ieee.org         Voice (503)-520-1993
KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs