Andrey Turbanov created LOG4J2-2769:
---------------------------------------
Summary: AtomicMoveNotSupportedException shouldn't be logged as
ERROR
Key: LOG4J2-2769
URL: https://issues.apache.org/jira/browse/LOG4J2-2769
Project: Log4j 2
Issue Type: Improvement
Components: Appenders
Affects Versions: 2.13.0
Reporter: Andrey Turbanov
Fix For: 2.13.1
When RollingFileAppender moves file to another folder, it tries to use
[ATOMIC_MOVE|https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/file/StandardCopyOption.html#ATOMIC_MOVE]
option as most strong one approach.
In many common production cases this approach *always* fails, and
{{RollingFileAppender}} fallbacks (which is good) to use
[File.renameTo|https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/File.html#renameTo(java.io.File)]
method. One of such common case - using network filesystem for _cold_ logs
(E.g. CIFS).
When atomic move fails it prints error to the log. Something like this:
{code}
ERROR Unable to move file /opt/log/console.60465.pp1.log to
/opt/case/20200130/console.60465.pp1.20200130_193421.log:
java.nio.file.AtomicMoveNotSupportedException /opt/log/console.60465.pp1.log ->
/opt/case/20200130/console.60465.pp1.20200130_193421.log: Invalid cross-device
link
{code}
Such logs are very distracting and can lead to unnecessary monitoring alerts.
I suggest to lower logging level for such case to INFO or WARN. As it's
*expected* scenario.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
