[
https://issues.apache.org/jira/browse/LOG4J2-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321904#comment-16321904
]
Claire Villard commented on LOG4J2-2168:
----------------------------------------
Juste before the timestamp goes back in the past, I see a reconfiguration was
done, using a new version of the file on the filesystem.
{code}
2017-12-13 17:41:58,334 main DEBUG Reconfiguration complete for
context[name=18b4aac2] at URI /data/hazelcast/log4j2.xml
(org.apache.logging.log4j.cor
e.LoggerContext@79079097) with optional ClassLoader: null
{code}
Maybe the change of the timestamp is related to a known behavior of Log4J with
timezones, like described here:
https://stackoverflow.com/questions/3218144/log4j-problem-with-timezone ? The
gap of 1 hour matches our timezone (GMT+1).
We certainly didn't changed the clock manually, I will ensure it wasn't done by
something or someone else.
Furthermore, we observe the deletion of the files not only when Log4J is
reconfigured.
> 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)
