Log rotating of tomcat7 finds too old files.

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.

On the very interesting +0 vs -0 discussion I read the manpage that due to rounding +0 actually means yesterday. So while +/-0*24 is surely 0 we know that in the special case +0*24 is actually a day.
So -0 might just be a day in the other direction?

Setting incomplete since I'll wait on your feedback to my suggestions for now.
That should not stop others to chime in in case there are other ideas.

> 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.

I get your point and therefore simply disabled compression for now, which was responsible the error mails from cron.

> 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?

Yes.

> So you end up with a small log from day 1 zipped and a huge unzipped log of days 2-days-of-month.

Partly correct, because it's about my own web apps, not Tomcat itself, and those log errors only. As errors don't occur very often, the file might be pretty small for a whole month, even of size 0. So the problem is not file size, but the approach trying to compress it each and every day even if it's size 0, just because all "old" files should be compressed. And because those files are of size 0 most of the time, it doesn't make sense to name them by day in opinion.

> Plus day-of-month-1 warnings that there was a file in the way right?

Correct and that's a bit annoying.

> I think since you customized from the default which is logs per day to become logs per month.

I didn't change Tomcat itself, only my own web apps are logging per month by default into subdirs of /var/log/tomcat7. So in fact I have both, Tomcat still logging per day, me logging per month. Simply because I prefer per month, but don't care enough for Tomcat itself to change it and customize working default configs.

I'll set it to confirmed, although I'm not sure what to do in general to cover your case and the potential others as well. Because if we consider this a default case that the default config should handle well, there could be way more.

I found another report about the same - which increases the severity in a sense of being an issue for more people.

There as well no zipping seemed to be the solution.
"To silence the cron messages, an easy workaround is to disable log compression in /etc/default/tomcat7 by setting "LOGFILE_COMPRESS=0". This will bypass the problematic section of /etc/cron.daily/tomcat7."