CODEWITHSUNDEEP
javaloggingfilesystemsslf4jlogback
Sam
Sam

Reputation: 6900

delete log file in runtime and slf4j+logback don't create it again

I using SLF4J + Logback as logging infrastructure in my application. logback.xml has following content in my app:

<?xml version="1.0" encoding="UTF-8" ?>
<configuration scan="true" scanPeriod="5 seconds">
    <jmxConfigurator />
    <property name="DIR" value="${LOG_DATA_HOME}"/>
    <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> 
        <file>${DIR}/loghome/last.log</file> 
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> 
          <fileNamePattern>${DIR}/loghome/log-%d{yyyy-MM-dd}.%i.log</fileNamePattern> 
          <timeBasedFileNamingAndTriggeringPolicyclass="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"> 
               <maxFileSize>10MB</maxFileSize> 
          </timeBasedFileNamingAndTriggeringPolicy> 
        </rollingPolicy> 
        <encoder>
          <pattern>%-5level %date- %X{_diagKey} - %logger - %msg %n </pattern>
        </encoder>
    </appender> 
    <logger name="net.sf.ehcache" additivity="false">
        <level value="error" />
        <appender-ref ref="FILE" />
    </logger>
    <root level="error">
        <appender-ref ref="FILE" />
    </root>
</configuration>

My application running in linux suse and JRE 1.6.

My question is: I deleted all log files(contain last file) from file system in times interval(for several reasons such as restriction of physical memory and etc) when my app running, but my app don't create log files again while I restart my app.

Anyone knows reasons of above behavior and solution for it?

EDITED I get more detail by OnConsoleStatusListener of logbak:

11:00:33,640 |-ERROR in c.q.l.c.recovery.ResilientFileOutputStream@17459938 - IO failure while writing to file [\loghome\last.log] java.io.IOException: The handle is invalid
    at java.io.IOException: The handle is invalid
    at  at java.io.FileOutputStream.writeBytes(Native Method)
    at  at java.io.FileOutputStream.write(FileOutputStream.java:260)
    at  at ch.qos.logback.core.recovery.ResilientOutputStreamBase.write(ResilientOutputStreamBase.java:52)
    at  at java.io.OutputStream.write(OutputStream.java:58)
    at  at ch.qos.logback.core.encoder.LayoutWrappingEncoder.doEncode(LayoutWrappingEncoder.java:103)
    at  at ch.qos.logback.core.OutputStreamAppender.writeOut(OutputStreamAppender.java:193)
    at  at ch.qos.logback.core.FileAppender.writeOut(FileAppender.java:220)
    at  at ch.qos.logback.core.OutputStreamAppender.subAppend(OutputStreamAppender.java:217)
    at  at ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:108)
    at  at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:88)
    at  at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:64)
    at  at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:285)
    at  at ch.qos.logback.classic.Logger.callAppenders(Logger.java:272)
    at  at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:473)
    at  at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:427)
    at  at ch.qos.logback.classic.Logger.debug(Logger.java:534)
    at  at Test.main(Test.java:17)

Upvotes: 1

Views: 4068

Answers (2)

kasur
kasur

Reputation: 1590

Even though the questioner mentioned that the logs had not been recreated even after the application has been restarted, there is slightly different issue that is somewhat specific to the unix/linux treating deletion of the file that is in use.

This is not the issue of course from the perspective of OS, but rather should be properly taken into consideration by the logging applications like logback, slf4j, etc.

You can actually see that type of improvement open for logback here. This indicated that there is indeed the situation that you cannot delete the log file on the fly on Unix/Linux and have it recreated automatically.

Upvotes: 1

Ceki
Ceki

Reputation: 27490

<configuration debug="true"> is your friend. See also the relevant documentation.

Upvotes: 1

Related Questions