
在journalctl --verify
一些明顯神秘的內容中(因為我在使用谷歌的互聯網上沒有發現任何關於這種現象的合理解釋)輸出顯示:
# journalctl --verify 2>&1 | grep -v '^PASS: '
7fffa0: Unused data (entry_offset==0)
7fec48: Unused data (entry_offset==0)
7ffe20: Unused data (entry_offset==0)
7ffed0: Unused data (entry_offset==0)
7ffd50: Unused data (entry_offset==0)
7ffda0: Unused data (entry_offset==0)
7ffdf0: Unused data (entry_offset==0)
這就產生了以下問題:
- 這是在哪裡記錄的?
- 這是什麼意思?
- 管理員是否因此保持警覺?
- 或可以忽略嗎?如果是這樣,那麼為什麼它存在呢?
- 如何擺脫這樣的條目?
- BCP對此有何回應?
預先感謝您的任何提示。
答案1
的提交訊息https://cgit.freedesktop.org/systemd/systemd/commit/?id=92fba83e
日誌驗證:允許未連結的資料條目
有時,條目未成功寫入,最終會得到「未連結」、未連接到任何條目且未被任何條目使用的資料項目。這種情況通常會發生在我們寫core dump的時候,初始的小資料欄位寫入成功,但是巨大的COREDUMP=欄位沒有寫入。這種情況很難避免,但結果大多是無害的。因此僅警告未使用的資料項。
另外,更詳細說明日誌檔案驗證失敗的原因。這應該有助於診斷日誌故障模式,而無需求助於十六進位編輯器。
https://bugs.freedesktop.org/show_bug.cgi?id=65235(特別是請參閱錯誤報告所附的 system.journal)。
解釋了為什麼上述錯誤報告的最終評論指出:
我可以安全地忽略那些嗎?
是的。
我可以看到此類訊息在臨時磁碟已滿的情況後仍持續很長時間。根據上述內容,我的解釋是,他們報告了正常操作期間也可能發生的異常情況,而該異常的存在不會造成任何進一步的傷害。