On Sun, 2004-02-08 at 14:10, Les Niles wrote:
On Sun, 08 Feb 2004 13:59:06 -0500 Barry Warsaw <barry@python.org> wrote:
Have you tried setting SYNC_AFTER_WRITE=Yes in your mm_cfg.py file?
-Barry
No, not yet.
I'd like to get a sense from folks as to whether I should turn on SYNC_AFTER_WRITE for MM 2.1.5. If so, should I keep the configuration variable or just hard-code enable it? Note that with the pending.pck and requests.pck rewrite I recently implemented, I'm always fsync'ing the files.
That's one of the mitigation steps the lack of which demonstrates why I should be kept away from computers. But whether the writes succeed or fail or trash the file, I couldn't see how both config.pck and config.pck.last got corrupted. If it's some subtle bug in the program's logic, that might be worth fixing, but if it's just some serious nastiness on the part of the filesystem then nevermind.
The only way I can see this happening is if the system calls succeed, but that the data gets corrupted before its flushed out to disk. So the writes and closes of the tmp files never raise exceptions, the rename dance is done, and then you're left with a corrupt .last file. If for some reason this is happening, turning on fsync should expose the problem because presumably, that call won't succeed unless the data is flushed to disk.
Try setting SYNC_AFTER_WRITE to Yes and restarting Mailman.
-Barry