[Dovecot] Dot Lock probelm resolution

Stewart Dean sdean at bard.edu
Fri Jun 8 21:39:52 EEST 2007


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:
>> 2) Is it syntactically correct? 
> I think so, though highly obfuscated and semantically worthless.
>> 3) 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 at bard.edu  voice: 845-758-7475, fax: 845-758-7035



More information about the dovecot mailing list