ppkarwasz commented on issue #3660:
URL:
https://github.com/apache/logging-log4j2/issues/3660#issuecomment-3132190567
Hi @umike72,
Apologies for the delayed response: we’ve got quite a backlog, but
fortunately this is one of those issues that only comes up twice a year 😄.
> * Around 1AM the relevant log files are rotated. Not sure why the rotation
is not occurring around midnight.
> * The previous day's log file contents are lost, replaced instead with log
entries from the current day, with timestamps between midnight and 1AM.
> * The current log file contains entries from 1AM onwards.
Based on your description, I believe the issue is caused by how
`CronExpression` evaluates scheduled times, especially around DST Fall Back
transitions, and how the asynchronous `CronRunnable` interprets them.
### ⏰ Rotation Timing at 1:00 AM
The rotation you're seeing at 1:00 AM (presumably due to the DST fallback)
may correspond to an attempt to rotate at **00:00 standard time**.
This behavior is interesting, but I wasn't able to reproduce the
double-rotation scenario one hour apart in either `Australia/Sydney` (where DST
ends at 3:00 AM) or `America/Santiago` (where DST ends at 24:00: a potentially
confusing boundary that might be interpreted as 00:00 standard time).
### 📁 Loss of Log Entries
The missing logs are expected when the file pattern evaluates to the same
string during **two different rotations**. This can happen if two rotations are
spaced too close apart:
* In your **hourly rotation test**, where the file pattern `%d{yyyy-MM-dd}`
omits the hour, causing every hourly rollover to write to the same daily file.
* If (hypothetically) an extra rotation occurs at **00:00 standard time**
during a **Fall Back** transition. While I couldn't reproduce this behavior,
it's possible if the scheduler misinterprets the repeated hour.
* During the **Spring Forward** transition, when the day is only 23 hours
long. In this case, two rotations may fall within the same 24-hour window, and
due to a bug in `CronExpression`, both use the same file name.
### 🧪 For Contributors
I’ve pushed a few (currently failing) unit tests to the
`fix/2.x/3660_cron-triggering-policy` branch that reproduce the date ambiguity
during DST transitions. While I don't plan to work on a fix myself right now,
anyone interested in contributing a patch is more than welcome to pick it up.
### 🛠️ Workaround
As a workaround, you can replace `CronTriggeringPolicy` with
`TimeBasedTriggeringPolicy`. The behavior is nearly identical, with one key
difference:
* `CronTriggeringPolicy` schedules rollovers asynchronously at fixed times.
* `TimeBasedTriggeringPolicy` triggers a rollover **on the first log event**
that occurs after the rollover time.
To switch, update your config by replacing:
```properties
appender.rolling_logfile1.policies.type = Policies
appender.rolling_logfile1.policies.cron.type = CronTriggeringPolicy
appender.rolling_logfile1.policies.cron.schedule = 0 0 0 ? * * *
```
with:
```properties
appender.rolling_logfile1.policy.type = TimeBasedTriggeringPolicy
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
