Comment 1 for bug 1694923

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.