Public bug reported: I've additionally described that problem on some other topic on SO:
https://superuser.com/questions/1214566/why-does-the-behaviour-of-find- differ-using-daystart-and-mtime-0-vs-0 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@...:/var/log/tomcat7/.../RebootDevice# ls -lisa > [...] > 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@...:/var/log/tomcat7/.../RebootDevice# find . -name \*.log -daystart > -mtime +0 > ./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. ** Affects: tomcat7 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1694923 Title: Log rotating of tomcat7 finds too old files. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tomcat7/+bug/1694923/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
