After a log file is deleted by mistake, a new rollover file cannot be created.

[kingdomhit]

Description

In earlier versions, such as 2.18.0, even if log files are deleted accidentally, the deleted files are automatically generated when the rollback conditions are met.
But now, it doesn't work when we use log4j 2.23.1.

name: ROLLING_FILE
policies:
sizeBasedTriggeringPolicy: {size: 100MB}
timebasedtriggeringpolicy: {interval: '1'}

Configuration

Version: [Log4j version]
2.23.1
Operating system: [OS and version]
linux
JDK: [JDK distribution and version]
JDK8

Logs

 ERROR Unable to write to stream /opt/logs/app/app-system.log for appender ROLLING_FILE org.apache.logging.log4j.core.appender.AppenderLoggingException: Error writing to stream /opt/logs/app/app-system.log
        at org.apache.logging.log4j.core.appender.OutputStreamManager.writeToDestination(OutputStreamManager.java:265)
        at org.apache.logging.log4j.core.appender.FileManager.writeToDestination(FileManager.java:335)
        at org.apache.logging.log4j.core.appender.rolling.RollingFileManager.writeToDestination(RollingFileManager.java:385)
        at org.apache.logging.log4j.core.appender.OutputStreamManager.flushBuffer(OutputStreamManager.java:296)
        at org.apache.logging.log4j.core.appender.OutputStreamManager.flush(OutputStreamManager.java:307)
        at org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.directEncodeEvent(AbstractOutputStreamAppender.java:229)
        at org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.tryAppend(AbstractOutputStreamAppender.java:220)
        at org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:211)
        at org.apache.logging.log4j.core.appender.RollingFileAppender.append(RollingFileAppender.java:337)
        at org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:160)
        at org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:133)
        at org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:124)
        at org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:88)
        at org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:705)
        at org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:663)
        at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:639)
        at org.apache.logging.log4j.core.config.LoggerConfig.logParent(LoggerConfig.java:696)
        at org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:665)
        at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:639)
        at org.apache.logging.log4j.core.async.AsyncLoggerConfig.log(AsyncLoggerConfig.java:154)
        at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:540)
        at org.apache.logging.log4j.core.config.AwaitCompletionReliabilityStrategy.log(AwaitCompletionReliabilityStrategy.java:67)
        at org.apache.logging.log4j.core.Logger.logMessage(Logger.java:155)
        at org.apache.logging.log4j.spi.ExtendedLoggerWrapper.logMessage(ExtendedLoggerWrapper.java:281)
        ...
        at com.google.common.util.concurrent.AbstractScheduledService$ServiceDelegate$Task.run(AbstractScheduledService.java:234)
        at com.google.common.util.concurrent.Callables.lambda$threadRenaming$3(Callables.java:105)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:750)
Caused by: java.io.IOException: Stream Closed
        at java.io.FileOutputStream.writeBytes(Native Method)
        at java.io.FileOutputStream.write(FileOutputStream.java:326)
        at org.apache.logging.log4j.core.appender.OutputStreamManager.writeToDestination(OutputStreamManager.java:263)
        ... 37 more

Reproduction

This commit : 3bc608d
RollingFileManager private boolean rollover(final RolloverStrategy strategy)
before: return true ---> Now: return success;
After we rollback this change , it works.

[ppkarwasz]

@kingdomhit,

Sorry for the delay, your report slipped through our hands.

You are right the solution to #1445 provided by #1549 was not complete and it caused a regression.
The File.delete() call can fail for two reasons:

• if an error occurred deleting the file. In such a case returning false to stop the rollover is the right behavior IMHO.
• if the fail does not exist. In such a case the method should return true.

The problem could be solved by switching from the incoherent File class to the new Path class (see #2117).
I am adding this to the 2.25.0 milestone. If you could provide a PR we would happily review it (in a timely manner this time 😉).