On 7 Nov 2017, at 21.33, Stephan von Krawczynski <skraw...@ithnet.com> wrote: > > > Me again have to stress that our former implementation of the lda process did > do exactly nothing to all the dovecot files, and everything worked pretty > well. We had no problems in years. So I really wonder if it wouldn't be the > best way to simply cut away all the heavy dovecot magic from the lda as an > option. All it really needs to do is pipe the mail into a temp file, do the > sieve stuff and learn from it where to rename this temp file to, basically. > On the other hand you have lots of config parameters in dovecot dealing with > different approaches to lock files (from fcntl to dotlock). I would expect at > least one of them to work over NFS.
I suppose you could create a unique new per-delivery temporary directory where dovecot-lda writes the mail, so it knows nothing about the user's real home/mail directory. Then move it from there to Maildir/tmp/ -> rename to Maildir/new/. I suppose you'd need to copy the Sieve script to the temp directory. Not sure if something would have to be done with .dovecot.lda-dupes. > And we do see stuff like: > > 2017-11-07T00:46:59.102961+01:00 mail-a05 dovecot: > lda(someb...@somedomain.com): > Warning: Locking transaction log > file <nfs-path>/dovecot.index.log took 40 seconds (appending) > > So some locking seems to work. The problem isn't locking, but caching of data. Especially because Dovecot doesn't lock when reading files.
