java.util.logging FileHandler.count 不工作

Posted 2023-02-26

【中文标题】java.util.logging FileHandler.count 不工作

【英文标题】：java.util.logging FileHandler.count not working

【发布时间】：2014-04-05 19:53:33

【问题描述】：

我正在为一个项目使用 java.util.logging，但配置有问题。我有一个我知道正在读取的 logging.properties 文件，因为例如对级别和文件处理程序模式的更改生效。

问题在于，即使我试图强制只存在一个日志文件，java.util.logging 仍坚持创建其他日志文件。我已阅读docs，这是 FileHandler 的示例配置：

java.util.logging.FileHandler.pattern = server.log
java.util.logging.FileHandler.limit = 500000
java.util.logging.FileHandler.count = 1
java.util.logging.FileHandler.append = false
java.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter

结果是文件被创建为 server.log.1、server.log.2 等。理想情况下，我不希望 append 为真（似乎没有什么不同......），我只是想要每次启动程序时都会创建一个新的日志文件，可能会覆盖现有文件。在任何时候，我的目录中的日志文件都不应超过 count。

更改追加和计数似乎没有任何区别。在模式中使用 %u 和 %g 等似乎也没有太大区别。我仍然不断收到使目录混乱的 server.log.n 文件。

每个创建的文件还附带一个 .lck 文件。为什么要创建它们，它们可能是罪魁祸首吗？

编辑：

不知道为什么我以前没有尝试过，但是手动删除 .lck 文件会导致事情按预期工作。所以现在真正的问题是：为什么要创建 .lck 文件（不正确的关闭？）以及如何处理？

【问题讨论】：

关闭 FileHandler 时删除锁定文件。通常，当关闭挂钩 j.u.l.LogManager$Cleaner 完成时，FileHandler 会关闭。您提到您正在使用 cltr-c 强制关闭。我会假设在这种情况下不会执行关闭挂钩。

正如你所指出的，LogManager 的构造函数是：Runtime.getRuntime().addShutdownHook(new Cleaner()); .这应该拦截 ctrl-c 类型的关闭。

【参考方案1】：

只有当 FileHandler 检测到 server.log 文件被锁定时才会发生这种情况。您要么同时运行两个 JVM，要么同时打开两个指向相同文件名的 FileHandler 实例，要么另一个进程在 FileHandler 打开之前锁定了 server.log 文件。

相关：Is java.util.logging.FileHandler in Java 8 broken?、JavaLogger randomly writes to a second file 和 FileLock。

【讨论】：

这似乎是真的。但是...我正在从 cygwin 环境中的脚本启动我的服务器。使用 cltr-c 强制关闭它不会留下任何进程。我可以再次启动服务器并毫无问题地绑定到同一个端口。然后我只能想象这是一个cygwin问题。但是只是删除日志文件没有问题，它们似乎没有被锁定......

我添加了指向答案的链接。在启动时记录 JVM pid，然后比较每个日志文件中的 id。

我为此添加了代码，但我不明白我应该比较什么？日志文件中的 pid 不同，然后 ps 显示这些进程中没有一个仍在运行。

cygwin 可能没有按预期执行文件锁定。删除所有日志和 lck 文件。执行您的工作的一开始和一停止。保留哪些文件，其中包含哪些 PID？