Time Based Rollover in 0.9.17
I've noticed that some of my applications using logback have stopped doing their time-based rollover. This change coincides with my upgrade of those apps from 0.9.16 to 0.9.17. These are apps that do not run continously - they are kicked off via cron a couple times a day. Those processes that do run continuously (such as the webserver) do still rollover correctly. Anyone else seen this change in behaviour? Is there any change in configuration needed for 0.9.17? Or is it a bug? -- Stephen Duncan Jr www.stephenduncanjr.com
Hello Stephen, I reopened http://jira.qos.ch/browse/LBCORE-26 as another user made a similar complaint. Stephen Duncan Jr wrote:
I've noticed that some of my applications using logback have stopped doing their time-based rollover. This change coincides with my upgrade of those apps from 0.9.16 to 0.9.17. These are apps that do not run continously - they are kicked off via cron a couple times a day. Those processes that do run continuously (such as the webserver) do still rollover correctly.
Anyone else seen this change in behaviour? Is there any change in configuration needed for 0.9.17? Or is it a bug?
-- Stephen Duncan Jr
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
Thanks. I verified that reverting my projects last night to 0.9.16 did fix it so that those cron-scheduled apps did roll-over the log file when run again this morning. -Stephen On Tue, Sep 15, 2009 at 6:13 AM, Ceki Gulcu <ceki@qos.ch> wrote:
Hello Stephen,
I reopened http://jira.qos.ch/browse/LBCORE-26 as another user made a similar complaint.
Stephen Duncan Jr wrote:
I've noticed that some of my applications using logback have stopped doing their time-based rollover. This change coincides with my upgrade of those apps from 0.9.16 to 0.9.17. These are apps that do not run continously - they are kicked off via cron a couple times a day. Those processes that do run continuously (such as the webserver) do still rollover correctly.
Anyone else seen this change in behaviour? Is there any change in configuration needed for 0.9.17? Or is it a bug?
-- Stephen Duncan Jr
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
Hi Stephen, Thank you for this information. Logback has test cases for this situation (roll over in presence of start/stop). It appears that they did not catch the problem. Would it be possible for you to post your logback configuration file so that I can reproduce the problem? TIA, Stephen Duncan Jr wrote:
Thanks. I verified that reverting my projects last night to 0.9.16 did fix it so that those cron-scheduled apps did roll-over the log file when run again this morning.
-Stephen
On Tue, Sep 15, 2009 at 6:13 AM, Ceki Gulcu <ceki@qos.ch <mailto:ceki@qos.ch>> wrote:
Hello Stephen,
I reopened http://jira.qos.ch/browse/LBCORE-26 as another user made a similar complaint.
Stephen Duncan Jr wrote:
I've noticed that some of my applications using logback have stopped doing their time-based rollover. This change coincides with my upgrade of those apps from 0.9.16 to 0.9.17. These are apps that do not run continously - they are kicked off via cron a couple times a day. Those processes that do run continuously (such as the webserver) do still rollover correctly.
Anyone else seen this change in behaviour? Is there any change in configuration needed for 0.9.17? Or is it a bug?
-- Stephen Duncan Jr
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
Here it is: <?xml version="1.0" encoding="UTF-8" ?> <configuration scan="true"> <appender name="LOG" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>/var/log/zeugma/selectterms/selectterms.log </file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>/var/log/zeugma/selectterms/selectterms.%d{yyyy-MM-dd}.log.gz</FileNamePattern> <MaxHistory>30</MaxHistory> </rollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%date [%thread] %-5level %logger - %msg%n</Pattern> </layout> </appender> <root level="info"> <appender-ref ref="LOG" /> </root> </configuration> -- Stephen Duncan Jr www.stephenduncanjr.com On Tue, Sep 15, 2009 at 9:02 AM, Ceki Gulcu <ceki@qos.ch> wrote:
Hi Stephen,
Thank you for this information. Logback has test cases for this situation (roll over in presence of start/stop). It appears that they did not catch the problem. Would it be possible for you to post your logback configuration file so that I can reproduce the problem?
TIA,
Stephen Duncan Jr wrote:
Thanks. I verified that reverting my projects last night to 0.9.16 did fix it so that those cron-scheduled apps did roll-over the log file when run again this morning.
-Stephen
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
Here's some more information (partially a different bug/issue, but I think it might shed some light on this issue too): For the continuously running processes, I have another problem where ".tmp" files are being left around (and since they're uncompressed, this is pretty undesirable). For one continuously running process that doesn't log often, the tmp file is rarely produced/left. But for the one logging for a webserver, which logs frequently (set to DEBUG), there's a tmp file for every day recently. The information that may be of interest regarding the difference between 0.9.16 and 0.9.17 is the name of these tmp files 0.9.17 - webapps.log801253047879607.tmp 0.9.16 - webapps.2009-09-14.log1060406806683985.tmp Or maybe it's got nothing to do with anything, but I thought I'd provide the data. -Stephen On Tue, Sep 15, 2009 at 9:02 AM, Ceki Gulcu <ceki@qos.ch> wrote:
Hi Stephen,
Thank you for this information. Logback has test cases for this situation (roll over in presence of start/stop). It appears that they did not catch the problem. Would it be possible for you to post your logback configuration file so that I can reproduce the problem?
TIA,
participants (2)
-
Ceki Gulcu -
Stephen Duncan Jr