為什麼 JBoss 和 Logrotate 會創建充滿 NUL 字元的日誌文件？
我已設置 Logrotate 以每晚輪換我的 JBoss Application Server 4.2.2.GA 日誌。在輪換日誌文件並且 JBoss 再次開始寫入它們之後，新的日誌文件以與前一個日誌文件中的字元一樣多的 NUL 字元開頭，然後是新的日誌消息。例如，如果 JBoss server.log 文件的長度為 5000 字節，那麼在輪換之後，新的 server.log 文件將以 5000 個 NUL 字元開頭。幾天后，server.log 以 NUL 字元開頭，相當於所有前幾天日誌文件中的字元組合。似乎 JBoss 正在記住它在日誌文件中的位置，並在截斷文件中從中斷的地方開始。這是我的 JBoss 的 logrotate 配置：
/apps/jboss-4.2.2.GA/server/default/log/*log { daily rotate 30 compress notifempty copytruncate missingok nocreate }我不能每晚重新啟動 JBoss，因為那會導致過多的停機時間。我也不能使用 log4j DailyRollingFileAppender，因為它不會刪除舊的日誌文件。有沒有人讓 logrotate 與 JBoss 一起正常工作？
對於 log4j 寫入的文件，我們遇到了同樣的問題。解決方案是將 FileAppender 的屬性“Append”設置為“true”。在此更改之後，我們沒有看到文件在由 logrotate 等外部程序旋轉時具有 NUL 的問題。
根據我的經驗 - 我們不將 logrotate 與 Log4j 一起使用的原因是 logrotate 的工作方式是它重命名文件，然後指示程序關閉其日誌並使用舊文件名重新打開它們（不再存在） )，通常使用 HUP 信號。
但是不能告訴 Log4j 重新打開它的日誌文件，所以我看到你用它
copytruncate來複製文件 - 問題是 Log4j 使用緩衝寫入器來跟踪正在寫入的文件的目前位置以及何時截斷日誌文件 log4j 繼續從截斷之前停止寫入的位置寫入。根據您的文件系統實現，這應該創建“帶孔的文件” - 即您看到的 NULL 字元實際上並不存在 - 該文件實際上僅與實際數據一樣大，而 NULL 字元是您的查看器表示的方式洞。另一方面，一些文件系統不支持漏洞，當 Log4j 恢復寫入時，確實會用 NULL 字元填充文件。我建議 - 不要使用 logrotate，通過使用 RollingFileAppender （確實支持刪除舊文件）或使用 DailyRollingFileAppender 和從外部刪除舊文件的 cronjob 找到某種方法來旋轉 Log4j 中的文件（因為它本來是要完成的） ）。