[
https://issues.apache.org/jira/browse/LOG4J2-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16308361#comment-16308361
]
Remko Popma commented on LOG4J2-2168:
-------------------------------------
Thank you for reporting this.
Archived log files being deleted during rollover is obviously a serious matter.
Would it be possible to try if this behaviour can be reproduced with the latest
version, Log4j 2.10?
(Also, minor detail, but the configuration {{<Pattern>%d\{yyyy-MM-dd
HH:mm:ss,fff\} ...}} should be {{<Pattern>%d\{yyyy-MM-dd HH:mm:ss,SSS\} ...}}
with {{SSS}} for milliseconds - I doubt that this is related, I just noticed.)
> RollingFile appender make no archive
> ------------------------------------
>
> Key: LOG4J2-2168
> URL: https://issues.apache.org/jira/browse/LOG4J2-2168
> Project: Log4j 2
> Issue Type: Question
> Affects Versions: 2.7
> Reporter: Claire Villard
> Attachments: log_log4j.txt
>
>
> Hi,
> I run a Java app, with Log4J2, on Linux (mainly CentOS) servers.
> Here is my configuration file:
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <Configuration shutdownHook="disable" monitorInterval="30" status="trace">
> <Appenders>
> <RollingFile name="RollingFile" fileName="/data/logs/hazelcast.log"
> filePattern="/data/logs/hazelcast-%d{yyyy-MM-dd-HH}{CET}-%i.log.gz">
> <PatternLayout>
> <Pattern>%d{yyyy-MM-dd HH:mm:ss,fff}{CET} %-5p [%t] %C{2}
> (%F:%L) - %m%n</Pattern>
> </PatternLayout>
> <Policies>
> <SizeBasedTriggeringPolicy size="300MB" />
> <TimeBasedTriggeringPolicy />
> </Policies>
> <DefaultRolloverStrategy max="90"/>
> </RollingFile>
> </Appenders>
> <Loggers>
> <Root level="DEBUG">
> <AppenderRef ref="RollingFile"/>
> </Root>
> </Loggers>
> </Configuration>
> {code}
> We expect the log file to be rolled each hour, or when its size reaches 300MB.
> This behavior is observed on all our servers, except one, and we can't find
> why.
> On this server, the file is rolled, the file with the old logs is renamed and
> gzipped... and a few seconds after that, gets deleted.
> The files are not deleted if our application is not started, invalidating the
> hypothesis of another process on the server deleting them.
> Removing the line {{<DefaultRolloverStrategy max="90"/>}} did not changed
> anything.
> Changing the file pattern to make them roll each minute, or each day, did not
> changed anything neither. The files are always deleted.
> Another test we did on December, 13th: we created a few files with the
> expected pattern (rolling each minute):
> {code}
> [root@INCBMCBINTMD03 logs]# ll
> total 52912
> -rw-r--r-- 1 hazelcast hazelcast 48238592 Dec 20 2016
> hazelcast-2016-12-19-1.log
> -rw-r--r-- 1 hazelcast hazelcast 345052 Sep 1 01:59
> hazelcast-2017-08-31-1.log
> -rw-r--r-- 1 hazelcast hazelcast 1147 Dec 13 09:55
> hazelcast-2017-12-13-09-54-1.log.gz
> -rw-r--r-- 1 hazelcast hazelcast 783 Dec 13 09:58
> hazelcast-2017-12-13-09-57-1.log.gz
> -rw-r--r-- 1 hazelcast hazelcast 782 Dec 13 10:01
> hazelcast-2017-12-13-10-00-1.log.gz
> -rw-r--r-- 1 hazelcast hazelcast 463 Dec 13 10:09
> hazelcast-2017-12-13-10-08-1.log.gz
> -rw-r--r-- 1 hazelcast hazelcast 239 Dec 13 10:11
> hazelcast-2017-12-13-10-10-1.log.gz
> -rw-r--r-- 1 hazelcast hazelcast 1075 Dec 13 10:12
> hazelcast-2017-12-13-10-11-1.log.gz
> -rw-r--r-- 1 hazelcast hazelcast 465 Dec 13 10:14
> hazelcast-2017-12-13-10-13-1.log.gz
> -rw-r--r-- 1 hazelcast hazelcast 533 Dec 13 10:15
> hazelcast-2017-12-13-10-14-1.log.gz
> -rw-rw-r-- 1 hazelcast hazelcast 81184 Dec 13 10:51 hazelcast.log
> -rw-rw-r-- 1 hazelcast hazelcast 5469748 Sep 15 2016 hazelcast.log.old
> {code}
> We start the app, and 2 minutes later, the content of the directory is:
> {code}
> [root@INCBMCBINTMD03 logs]# ll
> total 52892
> -rw-r--r-- 1 hazelcast hazelcast 48238592 Dec 20 2016
> hazelcast-2016-12-19-1.log
> -rw-r--r-- 1 hazelcast hazelcast 345052 Sep 1 01:59
> hazelcast-2017-08-31-1.log
> -rw-rw-r-- 1 hazelcast hazelcast 92742 Dec 13 10:53 hazelcast.log
> -rw-rw-r-- 1 hazelcast hazelcast 5469748 Sep 15 2016 hazelcast.log.old
> {code}
> All the directories and files concerned by this configuration have the right
> permissions to be read, written or moved by the user running the app.
> We activated the "trace" mode of Log4J, some logs are attached. The problem
> occurred when these logs were produced, but we didn't find anything in them
> to help us figuring out what's happening.
> Any help would be greatly appreciated !
> Thanks in advance,
> Claire
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
