Problems with cnfs-spool after system-crash

Felix Schueller inn.workers-post at fschueller.cologne.de
Tue Aug 14 16:21:59 UTC 2001


[I have posted this to news.software.nntp and got no answer. Maybe
someone on this list can help me]

Hi,

on my old system iI had an Inn 2.3.[01] on a linux 2.2.18 kernel with
glibc 2.0.7. But after every systemcrash (if someone had switched the
power of or so) I had problems with the CNFS-buffers. All postings witch
came in between the last shutdown of inn and the crash were absent.

So I looked into cnfs.c to find a solution for my problem. And in cnfs.c
I found the variable "MMAP_NEEDS_MSYNC". 'man 2 msync' says:

|msync flushes changes made to the in-core copy of a file that was
|mapped into memory using mmap(2) back to disk. Without use of this call
|there is no guarantee that changes are written back before munmap(2) is
|called.

But the configure script of inn says that msync is not needed and sets
'#undef MMAP_NEEDS_MSYNC' in config.h. I think that can be the failure.
So I put '#define MMAP_NEEDS_MSYNC 1' manually in config.h to test it.

But unfortunately (or fortunately) I had no crashs during the last
months. And meanwhile I updated my system and now its a linux 2.4.3 with
glibc 2.2.2 and Inn 2.3.2.

And now on a sunday a thunderstorm caused a short powerbreak witch
crashed my computer. And after rebooting the system all postings were in
the cnfs-buffers even postings I've written just minutes before. Only a
run of makehistory was necessary. Now unfortunately I don't know exactly
why the problem occurs befor and not now. I think its the Problem with
msync but due to my systemchange I'm not sure. And I have no possibility
to check this.

Can anyone confirm or disprove this?

TIA & Cu
  Felix
-- 
A common mistake that people make when trying to design something completely
foolproof is to underestimate the ingenuity of complete fools.

Douglas Adams, Mostly Harmless, Chapter 12


More information about the inn-workers mailing list