I\'m currently trying to work out a method of tidying up Oracle Recover log files that are created by Cron...
Currently, our Oracle standby recover process is invoked b
Logrotate removes files according to order in lexically sorted list of rotated log file names, and also by file age (using last modification time of the file)
rotate is maximal number of rotated files, you may find. If there is higher number of rotated log files, their names are lexically sorted and the lexically smallest ones are removed.
maxage defines another criteria for removing rotated log files. Any rotated log file, being older than given number of days is removed. Note, that the date is detected from the file last modification time, not from file name.
dateformat allows specific formatting for date in rotated files. Man page notes, that the format shall result in lexically correct sorting.
dateyesterday allows using dates in log file names one day back.
To keep given number of days in daily rotated files (e.g. 7), you must set rotate
to value of 7 and you may ignore maxage
, if your files are created and rotated really every day.
If log creation does not happen for couple of days, a.g. for 14 days, number of rotated log files will be still the same (7).
maxage
will improve the situation in "logs not produced" scenarios by always removing too old files. After 7 days of no log production there will be no rotated log files present.
You cannot use dateformat
as OP shows, as it is not lexically sortable. Messing up with dateformat
would probably result in removing other rotated log files than you really wanted.
Tip: Run logrotate from command line with -d
option to perform a dry run: you will see what logrotate would do but doesn't actually do anything. Then perform a manual run using -v
(verbose) so that you can confirm that what is done is what you want.
The concept is:
Let cron to create and update the log files, but make small modification to create files, following logrotate standard file names when using default dateext
/data/tier2/scripts/logs/recover_standby_SID.log-`date +\%Y\%m\%d`.log
Use logrotate only for removing too old log files
/data/tier2/scripts/logs/recover_standby_SID.log
missingok
to let logrotate cleanup to happenrotate
high enough, to cover number of log files to keep (at least 7, if there will be one "rotated" log file a day, but you can safely set it very high like 9999)maxage
to 7. This will remove files which have last modification time higher than 7 days.dateext
is used just to ensure, logrotate searches for older files looking like rotated.Logrotate configuration file would look like:
data/tier2/scripts/logs/recover_standby_SID.log {
daily
missingok
rotate 9999
maxage 7
dateext
}
I am not sure, how is source recovery standby file created, but I will assume, Oracle or some script of yours is regularly or continually appending to a file /data/tier2/scripts/logs/recover_standby_SID.log
The concept is:
logrotate
/data/tier2/scripts/logs/recover_standby_SID.log
daily
will cause rotation once a day (in terms of how cron
understands daily
)rotate
must be set to 7 (or any higher number).maxage
set to 7 (days)dateext
to use default logrotate date suffixdateyesterday
used to cause date suffixes in rotated files being one day back.missingok
to clean older files even when no new content to rotate is present.Logrotate config would look like:
data/tier2/scripts/logs/recover_standby_SID.log {
daily
missingok
rotate 7
maxage 7
dateext
dateyesterday
}
Note, that you may need to play a bit with copytruncate
and other similar options which are related to how is the source log file created by external process and how it reacts to the act of rotation.
As per @Jan Vlcinsky, you can let logrotate add the date - just use dateyesterday
to get the right date.
Or, if you want to put in the date yourself, you can 'aim' at the name without the date , and then the names with the date will be cleaned up.
However, what I found is that if I don't have a log file there, logrotate doesn't do the cleanup of the files with dates.
But if you're prepared to have an empty log file lying around, then it can be made to work.
For example, to clean up /var/log/mylogfile.yyyymmdd.log after 7 days, touch /var/log/mylogfile.log
, then configure logrotate as follows:
/var/log/mylogfile.log { daily rotate 7 maxage 7 dateext dateformat .%Y%m%d extension .log ifempty create }
This entry, combined with the existence of mylogfile.log, triggers logrotate to clean up old files, as if they had been created by logrotate.
daily
, rotate
plus maxage
cause old log files to be deleted after 7 days (or 7 old log files, whichever comes first).
dateext
, dateformat
plus extension
causes logrotate to match our filesnames.
And ifempty
plus create
ensure that there continues to be an empty file there, or the log rotation would stop.
Another tip for testing, be prepared to edit /var/lib/logrotate.status to reset the 'last rotated' date or logrotate won't do anything for you.
You can use find
command to do that task easily! It will delete all 7 Days
old files. Put it in crontab
and run nightly basis:
$ cd /data/tier2/scripts/logs/
$ /usr/bin/find . -mtime +7 -name "*.log" -print -delete
Or Better way
$ /usr/bin/find /data/tier2/scripts/logs/ -mtime +7 -name "*.log" -print -delete;
(Updated) Your options are:
Initially, I thought that changing the dateformat to match your logs might work but as Reid Nabinger pointed out the date format was not compatible with logrotate anyway. Recently, I tried to configure the same thing but for Java rotated logs that I wanted logrotate to delete. I tried the configuration below but it kept trying to delete all logs
/opt/jboss/log/server.log.* {
missingok
rotate 0
daily
maxage 30
}
I ended up just implementing what Satish suggested - a simple find with rm script in cron.
FYI I know that this is an old question, but the reason why it does not work for you is because your dateformat is not lexically sortable. From the manpage:
dateformat format_string
Specify the extension for dateext using the notation similar to strftime(3) function. Only
%Y %m %d and %s specifiers are allowed. The default value is -%Y%m%d. Note that also the
character separating log name from the extension is part of the dateformat string. The sys-
tem clock must be set past Sep 9th 2001 for %s to work correctly. Note that the datestamps
generated by this format must be lexically sortable (i.e., first the year, then the month
then the day. e.g., 2001/12/01 is ok, but 01/12/2001 is not, since 01/11/2002 would sort
lower while it is later). This is because when using the rotate option, logrotate sorts all
rotated filenames to find out which logfiles are older and should be removed.
The solution is to either change to one that goes year-month-date, or call an external process to perform the cleanup.
(Unable to comment as not enough reputation)
I had a similar issue. By all accounts logrotate is useless for use on filenames with built in datestamps.
If all else was equal I would probably go with find
in a cron job.
For my own reasons I wanted to use logrotate and eventually found a way: https://stackoverflow.com/a/23108631
In essence it was a way of encapsulating the cron job in a logrotate file. Maybe not the prettiest or most efficient but like I said, I had my reasons.