Log rotating of tomcat7 finds too old files.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
tomcat7 (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
I've additionally described that problem on some other topic on SO:
My web apps hosted by Tomcat7 log into /var/log/tomcat7 as well, with the only difference that I name my log files per month instead of per day. The problem is that the default log rotating script with compression enabled finds those log files even though they didn't change at a particular day like "yesterday", but only some days before the last time. That leads to unnecessary error mails from cron because the files can't be zipped if they already have been zipped before in the same month. The reason for that is name clashes of course, because my names potentially exist pretty often already per month.
In general I can live with those messages coming once a while per month, because my log files only contain error messages, which simply don't occur that often. So the files shouldn't change very often and log rotating shouldn't try to zip the old files. But in fact it does try to zip those files every day even if they didn't change for some days.
Look at the following example, where in one of my own log dirs a log file is present which was last changed some days ago, at 29.05.2017, while we today have the 01.06.2017. That log file from the last month is found when executing the find used in the log rotating script, which is something I wouldn't expect.
> root@..
> [...]
> 1089049 0 -rw-r--r-- 1 tomcat7 tomcat7 0 Mai 29 09:09 2017-05.log
> 1089047 4 -rw-r--r-- 1 tomcat7 adm 402 Mai 26 10:22 2017-05.log.gz
> root@..
> ./2017-05.log
So what is the intended behaviuor of the log rotating script? Should it find all modified files AT LEAST changed 24 hours ago, but arbitrary old? If so, shouldn't that script have an upper limit to make it more compatible with names like mine?
How about something like the following:
> find . -name \*.log -daystart -mtime +0 -a ! -mtime +1
Using +2 and +3 seems to properly find my file changed some days ago, while +3 and +4 or +1 and +2 don't.
Hi Thorsten,
while I'm not the logrotate expert I tried to read into your case trying to understand it.
I see your issue being many files (since they change names often) being found and tried to be compressed.
For you question in the last paragraph:
"So what is the intended behavior of the log rotating script? Should it find all modified files AT LEAST changed 24 hours ago, but arbitrary old? If so, shouldn't that script have an upper limit to make it more compatible with names like mine?"
My unimportant opinion is - yes - it should find and try to compress all old files.
Because there is no guarantee the job ran on the former days. Things could have been broken/disabled/... for a random amount of days.
Therefore finding and trying to compress ALL old files is the right approach.
Now OTOH I understand your issue with the warning mail.
Also thinking about your case it will zip 2017-05.log on the second day of may, and then refuse to overwrite the zipped file right?
So you end up with a small log from day 1 zipped and a huge unzipped log of days 2-days-of-month. Plus day-of-month-1 warnings that there was a file in the way right?
I think since you customized from the default which is logs per day to become logs per month.
The right solution IMHO would then be to map (on just your system) this customization to the rest, which would mean also logrotate monthly - now since that rounds up how about:
find . -name \*.log -daystart -mtime +31
That would work for all months (+1 day on short months, 3 days later in February - but not too critical I think).
The other way would be to overwrite. So since you log into the same file for a month after the first .gz is created the logfile actually on the next day is a superset right?
If so you could try to call logrotate in a way to overwrite the gz and not complain (or remove target before rotating the file).
Please take no offense in anything I wrote - all this is up for discussion - I was just trying to think through your case.