On Sun, 2009-01-18 at 23:32 -0800, JANE CUA wrote:
sample temp files that gets create in /var/spool/mail -rw------ jane mail _43398509485894865jane
I'm certain Dovecot didn't create this file at least directly.
-rw------ jane mail jane.lock
This is a dotlock and it can be created by Dovecot. You could also
probably disable it. http://wiki.dovecot.org/MboxLocking http://wiki.dovecot.org/MailboxFormat/mboxI have put the squirrelmail+dovecot offline now. It's hard to simulate the problem when I am the only one testing it. The issues came about, when I put it up online and the users started to use it.
Disabling it meaning remarking the following? #mbox_read_locks = fcntl #mbox_write_locks = dotlock fcntl
You can disable dotlocks by setting:
mbox_write_locks = fcntl
But like the MboxLocking page says, you should make sure that the other software that accesses the mbox files also use fcntl locking. Otherwise you'll get corrupted files.
other users create these files randomly as well in /var/spool/mail, / var/spool/mail is an NFS mount.
Hmm. NFS is a pretty good suspect here. I know that in some situations
it creates such temp files, although they're usually
named .nfs.something. Are those files deleted or are they just lying
around? What size do they have?The _* files go away but for the .lock files, some of them don't go away and if they don't go, users no longer receives new emails, but can still send out emails. The temp file with _* has 0 file size, I don't remember what the .lock size it, I will see if I can simulate this again.
I guess the _* files are written when .lock file is deleted but another process still has the file open. But like I said, normally Linux uses ".nfs" prefix for them. I guess your kernel doesn't for some reason.
Anyway you shouldn't have .lock files lying around. Sounds like Dovecot (or something else) is crashing which leaves them. Have you looked if there are error messages in logs? http://wiki.dovecot.org/Logging