in our test setup, I am experiencing a strange behaviour on the
Shibboleth 2.3.2 IdP's logback logging:
The logfile rollover works fine, but the "MaxHistory" setting (as
described in
https://wiki.shibboleth.net/confluence/display/SHIB2/IdPProdLogging )
does not always ensure that old log files will be removed. If no log
data is written for a couple of days e.g. to the idp_audit.log (because
nobody logged in at the IdP), the old logfiles will not be deleted on
the next rollover.
Has anybody else experienced this? I remember that we switched to .gz
files some time ago, but we already had this problem with uncompressed
.log files before.
This is an excerpt of our logging.xml file:
<appender name="IDP_AUDIT"
class="ch.qos.logback.core.rolling.RollingFileAppender">
<File>/usr/share/shibboleth-idp/logs/idp-audit.log</File>
<rollingPolicy
class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<MaxHistory>7</MaxHistory>
<FileNamePattern>/var/log/shibboleth-idp/logs/idp-audit-%d{yyyy-MM-dd}.log.gz</FileNamePattern>
</rollingPolicy>
<encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
<charset>UTF-8</charset>
<Pattern>%msg%n</Pattern>
</encoder>
</appender>
-Manuel
--
To unsubscribe from this list send an email to users-un...@shibboleth.net
I was also hit by this a couple of weeks ago. It's a known problem in
logback (probably the relevant issue is
http://jira.qos.ch/browse/LBCORE-147). Ugly as it is, I switched to
purge old log files based on mtime triggered by cron.
Kristof
thank you for the link. For now, I will try the updated Logback 0.9.30
library (the Shibboleth IdP currently ships with Logback 0.9.27).
-Manuel