[ http://jira.qos.ch/browse/LBCORE-147?page=com.atlassian.jira.plugin.system.i... ] HC edited comment on LBCORE-147 at 7/4/11 5:28 PM: --------------------------------------------------- Hello, I can see the same issue on our production machines. We use logback and logs are not deleted using ch.qos.logback.core.rolling.TimeBasedRollingPolicy with ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP triggering policy. A subset of the original problem is the case when the log filename does not contain directory information. This particular issue can be replicated by slightly modifying one of the existing tests from logback's test suite: TimeBasedRollingWithArchiveRemovalTest.java. Please see the test named dailyChronologSizeBasedRolloverWhenLogFilenameDoesNotContainDirectory() in the attached file. Best Regards, Horace was (Author: hc): Hello, I can see the same issue on our production machines. We use logback and logs are not deleted using ch.qos.logback.core.rolling.TimeBasedRollingPolicy with ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP triggering policy. It seems issue can be replicated by slightly modifying one of the existing tests from logback's test suite: TimeBasedRollingWithArchiveRemovalTest.java. Please see the test named dailyChronologSizeBasedRolloverWhenLogFilenameDoesNotContainDirectory() in the attached file. It seems that if the log filename does not contain directory information no files are deleted. At a quick glance, the faulty code would be in SizeAndTimeBasedArchiveRemover.clean() 1. File parentDir = archive0.getParentFile(); 2. File[] matchingFileArray = FileFilterUtil.filesInFolderMatchingStemRegex(parentDir, stemRegex); The first line returns null for the specified case and hence FileFilterUtil.filesInFolderMatchingStemRegex() will return immediately when a null parameter is sent. Best Regards, Horace
RollingPolicy MaxHistory not deleting old files -----------------------------------------------
Key: LBCORE-147 URL: http://jira.qos.ch/browse/LBCORE-147 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.18 Environment: linux 2.6.18 64bits apache-tomcat-6.0.20 java/jre1.6.0_18 Reporter: Rafael Diaz Maurin Assignee: Ceki Gulcu Attachments: TimeBasedRollingWithArchiveRemovalTest.java
The MaxHistory does not do the trick : the old files are not deleted at all : cat logging.xml <appender name="IDP_ACCESS" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>/shibboleth-idp/logs/idp-access.log</File> <Append>false</Append> <ImmediateFlush>true</ImmediateFlush> <RollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>/shibboleth-idp/logs/old/idp-access-%d{yyyy-MM-dd_HH-mm}.log.gz</FileNamePattern> <MaxHistory>3</MaxHistory> </RollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%msg%n</Pattern> </layout> </appender>
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira