We are using rolling file appender in an IIS managed C# application. Our
log4Net deployment is configured with the following options specified in
basic.xml: <appendToFile value="false" /> <countDirection value="0" />
<maximumFileSize value="512KB" /> <maxSizeRollBackups value="100" />
<rollingStyle value="Once" /> <staticLogFileName value="false" />. The
file pattern for our log file name is
"abc_%date{yyyyMMdd_HHmmss}_%processid_.log".
We have observed in our production environment that occasionally
filenames would be created with patterns like
"abc_%date{yyyyMMdd_HHmmss}_%processid_.log.1",
"abc_%date{yyyyMMdd_HHmmss}_%processid_.log.1.2",
"abc_%date{yyyyMMdd_HHmmss}_%processid_.log.1.2.3", etc. We have
observed filenames with the dot+sequential numbers pattern after the
.log to be anything from ".1" to ".220". This is one of two unexpected
behaviours observed.
The second unexpected behaviour seems to a special case of the first
that occasionally causes IIS to hang (100% CPU consumption). An analysis
of several crash dumps taken at the time of the hang indicated that
RollingFileAppender had in memory a filename of the same pattern as
above but with the number of characters [base filename
pattern]+[recurring extension pattern] exceeding 255 characters. It is
very likely that an attempt to create a file by such name on NTFS would
throw exceptions at various levels - managed and native - and hence the
file itself is never created.
To the best of our knowledge, there were no events to trigger the
filename to be rolled. As indicated in the configuration options, we are
using RollingStyle of "Once". (The log file content is minimal at the
time the symptoms occur - total file size is about 2K - and the times of
occurrence are totally non related).
We have been unable to capture the workflow leading up to the symptoms
above due to the high number of users and document types in our
production environment. The permissions on the logging folder are
static. However, we have found a simple workflow in our lab environment,
using permissions, that produce similar symptoms. This workflow is:
- Right click on the logging folder and select "Properties"
- Under the "Security" tab ensure that IIS_WPG group doesn't have write
access to the logging folder.
- Restart IIS
- Launch our application and view a document. Check the logging folder
to make sure that a logfile is not created.
- View a few more documents
- Change the permission on the logging folder and ensure IIS_WPG group
has write access to the folder. DO NOT restart IIS after changing the
permission.
- Launch our application and view another document.
- At this point a logfile with a filename pattern described will be
found in the logging folder.
As mentioned, it is unlikely that permissions are the trigger in our
event but it is likely that the same code is creating these unexpected
patterns irrespective of the trigger.
