Journald corruption

Question

There have been several threads about this but the usual diagnosis seems to be that corruption is caused by lack of a shutdown hook or by unclean shutdowns of the system.
I'm seeing regular journal corruption even when I've had no unclean shutdowns and despite using the shutdown hook.
My question is whether this is considered "normal". That is, I assume it is not considered how things are meant to work but if it is a known issue experienced by everyone or a number of people, that's one thing. If not, I would like to know how I might investigate what might be causing it. Since the files are binary, I'm not sure how to tell what is occurring at the points journald identifies as problematic or quite what I'm meant to do with the information journalctl reports as the nature of the corruption of any particular file.
As far as I can tell, this isn't part of file system corruption more generally. (I see fsck clean stuff if I get an unclean shutdown, of course, but that's only expected. Otherwise everything seems OK.) That is, I don't think it is a hardware problem - at least, not a disk problem - or a general problem with the filesystem.
If this is "normal" is there any service which will remove corrupted journal files automatically? Checking for them and removing them is now routine but I don't see much good in doing it manually since the information I get about the corruption doesn't help to resolve the underlying problem.
Of course, I wouldn't want to bury the evidence if this is not expected as then I'd like to address the underlying cause if possible.
Note: Please refrain from turning this into a discussion of the relative merits or demerits of systemd. Experience unfortunately suggests it is not safe to take such courtesy for granted.

Answer 1

Yes, those are the type of messages. I cleaned up yesterday, but I already have another 2 files corrupted:
Invalid object contents at 84064░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 0%
File corruption detected at /var/log/journal/997d1b9ffaa8efe300b8ff4100003004/[email protected]6aeede08.journal:84064 (of 86016, 97%).
FAIL: /var/log/journal/997d1b9ffaa8efe300b8ff4100003004/[email protected]6aeede08.journal (Bad message)
Invalid object contents at 38352░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 0%
File corruption detected at /var/log/journal/997d1b9ffaa8efe300b8ff4100003004/[email protected]b66ab773.journal:38352 (of 712704, 5%).
FAIL: /var/log/journal/997d1b9ffaa8efe300b8ff4100003004/[email protected]b66ab773.journal (Bad message)
It is annoying because the journal does not seem to manage the amount of disk space it uses correctly if corrupt logs are present.
I am very pleased to here that others are seeing similar issues with no signs of any other trouble. That is, I'm not glad you are having issues per se but I am pleased that it suggests some sort of bug rather than, say, that my hard drive is dying!
I don't quite understand what the SplitMode being set to login by default does. All the cases I've seen start system@...  but the same is true of all my journal logs so I don't understand what is being split? Or are there other journal logs elsewhere which I'm not aware of?