How does one debug windows permissions - just to even see what they are? I tried cacls and I see all these terms like FILE_READ_ATTRIUTES, FILE_WRITE_EA, etc. which as far as I can tell are not defined ANYWHERE I can find on the web. Does anyone know what Windows 7 permission(s) would be necessary for a user to have in order for the rollover function of logback to work? I assume that it is doing a rename (or move) operation. On 06/05/2013 12:35 PM, Robert Kuhar wrote:
Every time this has happened to me the root cause has been a permissions problem. Do you have a means to tailing standard out/err to see if the tell tale "permissions" problem is showing up there?
Also, if your app isn't running when the trigger is me, it is my understanding and observation that the logs won't roll.
On Wed, Jun 5, 2013 at 10:18 AM, Steve Cohen <scohen@javactivity.org <mailto:scohen@javactivity.org>> wrote:
I have a logback configuration which specifies a daily rollover for a java swing application that is connected to a legacy backend and creates much log:
<appender name="LocalFile"
class="ch.qos.logback.core.__rolling.RollingFileAppender"> <File>${logdir}/local.log</__File> <rollingPolicy class="ch.qos.logback.core.__rolling.__TimeBasedRollingPolicy"> <!-- daily rollover -->
<fileNamePattern>${logdir}/__local.%d{yyyy-MM-dd}.log</__fileNamePattern> <!-- keep 10 days' worth of history --> <maxHistory>10</maxHistory> </rollingPolicy> <encoder> <pattern>%d [%t] %-5p %c{2} - %m%n</pattern> </encoder> <filter class="ch.qos.logback.classic.__filter.ThresholdFilter"> <level>INFO</level> </filter> </appender>
I am finding in production that sometimes the logfile doesn't roll. I am not sure whether the application is running at the moment when it's supposed to roll, if that matters. Initially I suspected Windows 7 permissions - a bloody nightmare - were responsible. I initially thought that it always rolled correctly on some machines, but not on others. But now I find a case on a single machine where rollovers happened on some days but not on others.
We are using logback v.1,0.7 and slf4j version 1.6.5. Yes, I know there are more recent versions but it would be a major hassle getting them deployed into our particular environment and I haven't seen this behavior in months of testing.
Can anyone point me in a direction leading to the solving of this issue? _________________________________________________ Logback-user mailing list Logback-user@qos.ch <mailto:Logback-user@qos.ch> http://mailman.qos.ch/mailman/__listinfo/logback-user <http://mailman.qos.ch/mailman/listinfo/logback-user>
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user