[ 
https://issues.apache.org/jira/browse/LOG4J2-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claire Villard updated LOG4J2-2168:
-----------------------------------
    Affects Version/s: 2.10.0

> 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, 2.10.0
>            Reporter: Claire Villard
>            Priority: Major
>         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
(v7.6.3#76005)

Reply via email to