For the record/archive, so some other unfortunate dovecot implementer won't spend weeks figuring out this particular way dotlocks can have problems... here is what was trashing our dotlocks
Basically, I was seeing this: May 14 15:59:58 mercury mail:warn|warning dovecot: IMAP(sdean): Our dotlock file /var/spool/mail/sdean.lock was deleted (kept it 1 secs)
May 14 15:59:58 mercury mail:err|error dovecot: IMAP(sdean): file_dotlock_delete() failed with mbox file /var/spool/mail/sdean: No such file or directory
Timo justifiably blamed the usual suspect, NFS, but when I dug into the maillog to see what was going on when the locks were getting trashed, in almost all cases, NFS wasn't involved. And I had recompiled procmail so that it used the same locking strategy (and checked it), deactivated NFS client attribute caching, etc., etc.
It turned out that my predecessor had done something 10 years ago that was arcane, inscrutable and kludgy in the .procmailrc file. This *purposefully* trashed the dotlock. Not knowing what it did when I took over (predecessor long gone, things in disarray), I left it in, because I worried that something would break if we removed it. We have perpetuated it in creation of all new accounts. This procmailrc stanza looks like this:
####### BEGIN SYS ADMIN ADDED LINES ####### ## !!!!!! Do not remove these lines !!!!!! ## They have been placed here by System Admin ## If removed, your mail will run slower and ## generate error messages!!!!!!!!
LOCKFILE #removes preexisting lockfile LOG='lockfile $DEFAULT$LOCKEXT ' TRAP="rm -f $DEFAULT$LOCKEXT" :0 $DEFAULT ####### END OF SYS ADMIN ADDED LINES ####### # IF YOU ADD STUFF, DO IT ABOVE THIS BLOCK #
I sent a note to the procmail mailing list hoping to get a clue of what is doing. Here are my Qs and their As:
- Is it syntactically correct? I think so, though highly obfuscated and semantically worthless.
- Is what it's doing real/worthwhile? No. My guess is it was a kludge to work around some error with an older version of procmail, if it ever served any function at all. Since we removed it, there have been no dotlocking errmsgs in the syslog.
--
Stewart Dean, Unix System Admin, Henderson Computer Resources
Center of Bard College, Annandale-on-Hudson, New York 12504
sdean@bard.edu voice: 845-758-7475, fax: 845-758-7035