On Sun, May 20, 2018 at 09:58:10PM +0200, Michael Biebl <bi...@debian.org>
wrote:
> Hm, too bad. Not sure what to do about this bug report now that we no
> longer have the offending journal file. I'm tempted to close it and
> reopen again, in case you run into it again and we can further debug this.
Would make sense, IMHO.
> > What I found interesting, though, is that jorunalctl --verify reports file
> > corruptiopn for a lot of files in /var/log/journal, although I didn't have
> > a crash (all files are newer than 14 days, and the machine has an uptime
> > of 40 days and even systemd-journald is running uninterrupted).
>
> That seems very strange. The only case where I personally ran into
> journal file corruption is when I had to power cycle the machine.
> But you said that journald ran uninterrupted for 40 days.
> Would it be possible that this is a hardware or file system issue?
The journal files themselves on btrfs, but that in itself shouldn't cause
corruption, at least not in the kernel versions we now use (and btrfs
turned out to be an excellent problem detector in the past, blowing
up at the tiniest issues). The server is indeed the only one showing
the problem, but on the other hand, it is also by far the busiest and
most-watched one. I also ran standalone memtest for half a night a few
weeks ago to rule out a memory problem, and it otherwise works fine,
despite crunching through a terabyte of data per day.
So, I don't think its a hardware issue, unless it's a hardware issue that
would affect only systemd, which is possible, but not that likely.
In any case, closing the bug report is the right thing to do if this
cnanot be further debugged. When I stumble over another such case I can
reopen it or create a new one.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
