logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: Issues with Log4j2 2.5 overwriting log files
Date Thu, 24 May 2018 14:30:15 GMT
That is a very old version of Log4j... can you update to the current
version?

Gary

On Thu, May 24, 2018, 06:23 <viscapi@cines.fr> wrote:

> Hi,
>
> We are having issues with log4j2 2.5 on some of our servers. When data is
> still being processed at midnight, the current log file doesn't rotate and
> past entries are being overwritten. The expected behavior would be to write
> the latest log entries to the new log file, without overwriting anything.
> When there's no activity around midnight, things are working just fine.
>
> I had a look at our log4j2.xml configuration file some days ago, and I
> think we're using the RollingFile appender:
>
>
> http://logging.apache.org/log4j/2.x/manual/appenders.html#RollingFileAppender
>
> <RollingFile name="RollingFile"
> fileName="log/arcsys_all.log.${date:yyyy-MM-dd}"
> filePattern="log/arcsys_all.log.%d{yyyy-MM-dd}">
>                         <PatternLayout>
>                                 <Pattern>%p %d{yyyy-MM-dd HH:mm:ss} [%t]
> (%F:%L)- %m%n</Pattern>
>                         </PatternLayout>
>                         <Policies>
>                                 <TimeBasedTriggeringPolicy interval="1"
> modulate="true"/>
>                         </Policies>
>                         <DefaultRolloverStrategy max="100">
>                                 <Delete basePath="log" maxDepth="2">
>                                         <IfFileName
> glob="*/arcsys_all-*.log.gz">
>                                                 <IfLastModified age="30d">
>                                         </IfLastModified>
>                                 </IfFileName>
>                         </Delete>
>                         </DefaultRolloverStrategy>
>                 </RollingFile>
>
> We tried raising the verbosity level to TRACE in order to find the root
> cause of this issue, but to no avail...
>
> As a workaround, we decided to stop processing new data a couple of hours
> before log rotation, and to make a back-up copy of the current log file to
> avoid any data loss.
>
> What are we doing wrong ?
>
> Any help would be greatly appreciated.
>
> Best regards,
>
> Samuel
>
> --
>
> Samuel VISCAPI
>
> CINES (Montpellier, France)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message