[
https://issues.apache.org/jira/browse/LOG4J2-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17284093#comment-17284093
]
Ralph Goers edited comment on LOG4J2-3018 at 2/13/21, 6:17 AM:
---------------------------------------------------------------
The small snippet of the debug log shown here doesn't indicate that there are
any errors. Are the files not being created? This log doesn't show any errors.
The error message should include the text from the exception that occurred
copying the file. Can you include those? Since you have debug enabled you
should also see the messages coming from the exceptions trying to move the
files before it resorts to copying. Please include those as well.
I am guessing your app was started on Feb 12. I fully expect that the date in
the file name will always be 2021-02-12 no matter how long the app stays up
since the filename is interpolated when the configuration is read.
I have a suspicion that what you really want to be using is the
[DirectWriteRolloverStrategy|http://logging.apache.org/log4j/2.x/manual/appenders.html#DirectWriteRolloverStrategy]
which allows you to write directly to the target file. On rollover a new file
is created that is directly written to. For that you would simply omit the
filename attribute altogether as shown here.
{code:java}
<RollingFile name="Rolling-${ctx:ServiceName}"
filePattern="${LOG_PATH}/RequestMgr_%d{yyyy-MM-dd}.log.gz">
<LevelRangeFilter minLevel="INFO" maxLevel="DEBUG" onMatch="ACCEPT"
onMismatch="DENY" />
<PatternLayout pattern="${LOG_PATTERN}" />
<Policies>
<TimeBasedTriggeringPolicy interval="1" modulate="true" />
</Policies>
</RollingFile>
{code}
In this case Log4j will write to a file matching the file pattern without the
.gz, .zip, etc. When a rollover occurs the RollingFileManager will simply
create the new file and log4j will start writing to it. The previous file will
then be compressed to the file with .gz, .zip, etc appended and the previous
file will be deleted.
I would also suggest you review Log4j's ability to manage a [log retention
policy|http://logging.apache.org/log4j/2.x/manual/appenders.html#Log_Archive_Retention_Policy:_Delete_on_Rollover]
so that you do not run out of space on your server.
was (Author: [email protected]):
The small snippet of the debug log shown here doesn't indicate that there are
any errors. Are the files not being created? This log doesn't show any errors.
The error message should include the text from the exception that occurred
copying the file. Can you include those? Since you have debug enabled you
should also see the messages coming from the exceptions trying to move the
files before it resorts to copying. Please include those as well.
I am guessing your app was started on Feb 12. I fully expect that the date in
the file name will always be 2021-02-12 no matter how long the app stays up
since the filename is interpolated when the configuration is read.
I have a suspicion that what you really want to be using is the
[DirectWriteRolloverStrategy|http://logging.apache.org/log4j/2.x/manual/appenders.html#DirectWriteRolloverStrategy]
which allows you to write directly to the target file. On rollover a new file
is created that is directly written to. For that you would simply omit the
filename attribute altogether as shown here.
{code:java}
<RollingFile name="Rolling-${ctx:ServiceName}"
filePattern="${LOG_PATH}/RequestMgr_%d{yyyy-MM-dd}.log.gz">
<LevelRangeFilter minLevel="INFO" maxLevel="DEBUG" onMatch="ACCEPT"
onMismatch="DENY" />
<PatternLayout pattern="${LOG_PATTERN}" />
<Policies>
<TimeBasedTriggeringPolicy interval="1" modulate="true" />
</Policies>
</RollingFile>
{code}
In this case Log4j will write to a file matching the file pattern without the
.gz, .zip, etc. When a rollover occurs the RollingFileManager will simply
create the new file and log4j will start writing to it. The previous file will
then be compressed to the file with .gz, .zip, etc appended and the previous
file will be deleted.
I would also suggest you review Log4j's ability to manage a [log retention
policy|http://logging.apache.org/log4j/2.x/manual/appenders.html#Log_Archive_Retention_Policy:_Delete_on_Rollover]
so that you do not run out of space on your server.
> Rollover log file at midnight not working
> -----------------------------------------
>
> Key: LOG4J2-3018
> URL: https://issues.apache.org/jira/browse/LOG4J2-3018
> Project: Log4j 2
> Issue Type: Bug
> Reporter: Rambabu Bikumandla
> Priority: Blocker
> Labels: log4j2.xml, routing
> Attachments: log4j2.xml, log4j2.xml
>
>
> Hi Team,
> I am migrating my project from log4j1.x to log4j2.11.2 version, while
> migration am seeing below issue could you please provide solution on it.
> *Log4j2 version :*
> *log4j-slf4j-impl-2.11.2*
> *log4j-1.2-api-2.11.2*
> *log4j-1.2-core-2.11.2*
> Issue: log files are not roll out every day midnight with new file name, it
> still writing it to old logs for some hours then switching to new logs.
> Below my log4j2.xml config.
> <Routing name="DEBUG">
> <Routes pattern="$${ctx:ServiceName}">
> <Route key="ConsuerManager">
> <RollingFile name="Rolling-${ctx:ServiceName}"
> {color:#ff0000}*fileName="/app/log/Consumer_${date:yyyy-MM-dd}.log*{color}"
> *{color:#ff0000}filePattern="/app/log/Consumer_%d\{yyyy-MM-dd}.log{color}*"
> append="true">
> <LevelRangeFilter minLevel="INFO" maxLevel="DEBUG" onMatch="ACCEPT"
> onMismatch="DENY" />
> <PatternLayout pattern="${LOG_PATTERN}" />
> <Policies>
> <TimeBasedTriggeringPo licy interval="1" modulate="true" />
> </Policies>
> </RollingFile>
> </Route>
> <Route key="AppProvider">
> <RollingFile name="Rolling-${ctx:ServiceName}"
> fileName="/app/log/Provider_${date:yyyy-MM-dd}.log"
> filePattern="/app/log/Provider_%d\{yyyy-MM-dd}.log" append="true">
> <LevelRangeFilter minLevel="INFO" maxLevel="DEBUG" onMatch="ACCEPT"
> onMismatch="DENY" />
> <PatternLayout pattern="${LOG_PATTERN}" />
> <Policies>
> <TimeBasedTriggeringPolicy interval="1" modulate="true" />
> </Policies></RollingFile></Route>
> </Routes>
> </Routing>
> *Sample Logs: consumer_2021-02-08.log - It should contain only Feb-08 but we
> are seeing Feb-09 also*
> [Feb/08/21 18:18:37] INFO com.app.apptest.Database.DbRequest - approval
> status of the myno: 125478412 Is ::W
> [Feb/08/21 18:18:37] INFO
> com.myapp.servicecore.ejb.monitor.AppTestsEJBMonitor
> [Feb/08/21 18:18:37] INFO
> com.myapp.servicecore.ejb.monitor.AppTestsEJBMonitor
> [Feb/08/21 18:18:37] INFO com.bi.myapp.consumer.utils.ConsumerHelper -
> conditional status for the myno ::4857154 is :: false
> [Feb/08/21 18:18:37] INFO com.app.apptest.Database.Database - Database
> initialized
> [Feb/08/21 18:18:37] INFO com.app.apptest.MyManagement.Database - Database
> initialized
> [Feb/08/21 18:18:38] INFO com.app.apptest.Database.DbTtion - mynoId :123456
> mynoID :45678
> [Feb/08/21 18:18:38] INFO com.bi.persistent.process.DBProcess - db is
> ::org.apache.db.oracle.DBCommandOracle@516c36a0
> [Feb/08/21 18:18:38] INFO com.bi.persistent.process.DBProcess - db is
> ::org.apache.db.oracle.DBCommandOracle@4ee951e2
> [{color:#FF0000}Feb/08/21 18:18:38{color}] INFO
> com.bi.myapp.restclients.CircuitImpactClient - constructor: Using environment
> Test to get URL info
> ..
> ..
> {color:#FF0000}[Feb/09/21 12:37:43{color}] INFO com.bi.myapp.util.Client -
> connectToId: Trying to connect to mail server;
> [Feb/09/21 12:37:44] INFO com.bi.myapp.util.Client - connectToId:
> Successfully connected to .
> [Feb/09/21 12:37:45] INFO com.bi.myapp.util.Client - readMails: There are 0
> messages to be processed
> [Feb/09/21 12:37:45] INFO com.bi.myapp.util.Client - readMails: Number of
> unread messages still in the
> [Feb/09/21 12:37:45] INFO
> com.myapp.servicecore.ejb.monitor.AppTestsEJBMonitor - updateLock invoked at
> 12:37:45 PM GMT took 3 milliseconds to execute.
> [Feb/09/21 12:37:45] INFO com.bi.myapp.scheduler.EmailReaderScheduler -
> ~
> "consumer_2021-02-08.log" [readonly] 6327556L, 273633483C
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
