What to do when "journalctl --verify" outputs "unused data"?

Question

In journalctl --verify some apparently mysterious (as I found no trace of any rationale explanation about this phenomenon on the Internet using Google) output shows up:

# 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)

This rises following Questions:

• Where is this documented?
• What does this mean?
• Has the admin to stay alert due to this?
• Or can it be ignored? If so, why does it exist then?
• How to get rid of such entries?
• What is the BCP in response to this?

Thanks in advance for any hints.

Answer 1

The commit message of https://cgit.freedesktop.org/systemd/systemd/commit/?id=92fba83e

journal-verify: allow unlinked data entries

Sometimes an entry is not successfully written, and we end up with data items which are "unlinked", not connected to, and not used by any entry. This will usually happen when we write to write a core dump, and the initial small data fields are written successfully, but the huge COREDUMP= field is not written. This situation is hard to avoid, but the results are mostly harmless. Thus only warn about unused data items.

Also, be more verbose about why journal files failed verification. This should help diagnose journal failure modes without resorting to a hexadecimal editor.

https://bugs.freedesktop.org/show_bug.cgi?id=65235 (esp. see system.journal attached to the bug report).

explains why the final comment of the above bug report states:

I can safely ignore those?

Yes.

I can see such messages persist long after a temporary disk full condition. My interpretation based on the above is that they report an anomaly which can also happen during normal operation, and the presence of which doesn't cause any further harm.