log4net RollingFileAppender 间歇性锁定文件问题
我们在开发和生产机器上发现了一个间歇性问题,即我们的日志文件没有被记录到。
当使用 Visual Studio 进行开发和调试时,我们在 VS 输出窗口中收到以下 log4net 错误消息:
log4net:ERROR [RollingFileAppender] Unable to acquire lock on file C:\folder\file.log.
该进程无法访问文件“C:\folder\file.log”,因为它正在被另一个进程使用。
log4net:ERROR XmlConfigurator: Failed to find configuration section 'log4net' in the application's .config file.
Check your .config file for the <log4net> and <configSections> elements.
配置部分应如下所示:
<section
name="log4net"
type="log4net.Config.Log4NetConfigurationSectionHandler,log4net" />
我们当前解决该问题的方法是重命名最后一个日志文件。我们当然希望这会失败(由于前面提到的文件锁定),但通常不会。由于 aspnet_wp.exe 进程的锁定,重命名有一两次失败。
我们的 log4net 配置部分如下所示:
<log4net>
<appender name="RollingLogFileAppender" type="log4net.Appender.RollingFileAppender">
<file value="C:\folder\file.log"/>
<appendToFile value="true" />
<datePattern value="yyyyMMdd" />
<rollingStyle value="Date" />
<maximumFileSize value="10MB" />
<maxSizeRollBackups value="100" />
<layout type="log4net.Layout.PatternLayout">
<header value="[Header]
"/>
<footer value="[Footer]
"/>
<conversionPattern value="%date %-5level %logger ${COMPUTERNAME} %property{UserHostAddress} [%property{SessionID}] - %message%newline"/>
</layout>
</appender>
<root>
<level value="INFO"/>
<appender-ref ref="RollingLogFileAppender"/>
</root>
</log4net>
如前所述,我们在计算机上间歇性地看到这种情况,但一旦问题发生,它就会持续存在。
We are seeing an intermittent issue on development and production machines whereby our log files are not getting logged to.
When running in development and debugging using Visual Studio we get the following log4net error messages in the VS output window:
log4net:ERROR [RollingFileAppender] Unable to acquire lock on file C:\folder\file.log.
The process cannot access the file 'C:\folder\file.log' because it is being used by another process.
log4net:ERROR XmlConfigurator: Failed to find configuration section 'log4net' in the application's .config file.
Check your .config file for the <log4net> and <configSections> elements.
The configuration section should look like:
<section
name="log4net"
type="log4net.Config.Log4NetConfigurationSectionHandler,log4net" />
Our current workaround for the issue is to rename the last log file. We would of course expect this to fail (due to the aforementioned file lock), but it normally doesn't. Once or twice the rename has failed due to a lock from the aspnet_wp.exe process.
Our log4net configuration section is shown below:
<log4net>
<appender name="RollingLogFileAppender" type="log4net.Appender.RollingFileAppender">
<file value="C:\folder\file.log"/>
<appendToFile value="true" />
<datePattern value="yyyyMMdd" />
<rollingStyle value="Date" />
<maximumFileSize value="10MB" />
<maxSizeRollBackups value="100" />
<layout type="log4net.Layout.PatternLayout">
<header value="[Header]
"/>
<footer value="[Footer]
"/>
<conversionPattern value="%date %-5level %logger ${COMPUTERNAME} %property{UserHostAddress} [%property{SessionID}] - %message%newline"/>
</layout>
</appender>
<root>
<level value="INFO"/>
<appender-ref ref="RollingLogFileAppender"/>
</root>
</log4net>
As mentioned, we are seeing this intermittently on machines, but once the issue happens it persists.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
尝试添加
到您的
元素。这会对性能产生一些影响,因为这意味着 log4net 将锁定文件、写入文件并为每个写入操作解锁文件(与默认行为相反,默认行为会长时间获取并保持锁定)。默认行为的一个含义是,如果您在一个网站下使用它,而该网站正在同一台计算机上运行的多个工作进程下执行,则每个工作进程都会尝试无限期地获取并保留该锁,其中两个是只是会输。将锁定模型更改为最小锁定可以解决此问题。
(调试时,不正常的终止和启动大量新的工作进程正是可能发生的事情。)
祝你好运!
Try adding
to your
<appender />
element. There is some performance impact because this means that log4net will lock the file, write to it, and unlock it for each write operation (as opposed to the default behavior, which acquires and holds onto the lock for a long time).One implication of the default behavior is that if you're using it under a Web site that is being executed under multiple worker processes running on the same machine, each one will try to acquire and hold onto that lock indefinitely, and two of them are just going to lose. Changing the locking model to the minimal lock works around this issue.
(When debugging, ungraceful terminations and spinning up lots of new worker processes is exactly the type of thing that's likely to happen.)
Good luck!
另请注意 log4net 常见问题解答:
Also be aware of the log4net FAQ:
如果您有
并添加,
那么在滚动发生时将会出现错误。
第一个进程将创建新文件并重命名当前文件。
然后下一个进程将执行相同的操作并获取新创建的文件并覆盖新重命名的文件。
导致最后一天的日志字段为空。
If you have
and add
then there will be an error while the rolling happens.
The first process will create the new file and the rename the current file.
Then next proces will do the same and take the newly created file and overwrite the newly renamed file.
Resulting in the logfiel for the last day being empty.