- Red Hat Enterprise Linux Server release 6.10 (Santiago)
- java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
- 301873 Mar 9 07:53 log4j-api-2.17.1.jar
1790452 Mar 9 07:53 log4j-core-2.17.1.jar
If a %i formatter in a filePattern includes a width specifier, e.g. "%4i" or "%04i", file renaming fails after a certain fixed number of cycles. After that, successive backups are renamed to the maximum cycle number and overwrite previous files of that same cycle number, regardless of min and max settings on the appender. Here are some failure modes I've found by testing:
- if filePattern contains %06i, cycling breaks after 100.
- if filePattern contains %006i, it breaks after 100 also.
- if filePattern contains %6i, it breaks after 10.
- if filePattern contains %06i and DefaultRolloverStrategy.min=10000, max=99999, it breaks after just 1.
Now, the doc doesn't mention the %i spec supporting width and leading zero modifiers in the manner of printf() or String.format() . Yet, those variations (which I think other users will also be tempted to try) work - until they don't. So apparently width and padding on that spec are implemented but buggy.
The doc for RollingRandomAccessFileAppender explicitly recommends these format modifiers:
... and/or a %i which represents an integer counter. The integer counter allows specifying a padding, like %3i for space-padding the counter to 3 digits or (usually more useful) %03i for zero-padding the counter to 3 digits.
...but I haven't verified that the problem occurs with that appender as well.
- relates to
LOG4J2-2941 zero-padding configuration problem