> >I've been following this thread: the bug is related with copying
> >mail across NFS in combination with cache locking, right?
> >Cor uses FBSD; but is this a bug that might impact other platforms
> >as well?
>
> The main bug here was that with lock_method=dotlock when cache file
> was bei
On Sep 11, 2008, at 9:00 PM, Jan van den Berg wrote:
I've been following this thread: the bug is related with copying
mail across NFS in combination with cache locking, right?
Cor uses FBSD; but is this a bug that might impact other platforms
as well?
The main bug here was that with lock_me
ED]>
To: "Dovecot Mailing List"
Cc: "Cor Bosman" <[EMAIL PROTECTED]>
Sent: Thursday, September 11, 2008 5:48 PM
Subject: Re: [Dovecot] error in 1.1.2
Conceptually at least, but I don't know if it applies cleanly without
them.
Cool! Ive just applied all pa
> Conceptually at least, but I don't know if it applies cleanly without
> them.
Cool! Ive just applied all patches you gave me to our production source,
and i'll sync it to a few servers to try it out and see :)
Cor
On Thu, 2008-09-11 at 17:00 +0200, Cor Bosman wrote:
> > > > Sep 10 22:06:41 imap dovecot: IMAP(scorpio):
> > > > rename(/var/spool/mail/dovecot-control/indexes/s/sc/scorpio/.Trash/dovecot.index.cache.lock,
> > > >
> > > > /var/spool/mail/dovecot-control/indexes/s/sc/scorpio/.Trash/dovecot.index
> > > Sep 10 22:06:41 imap dovecot: IMAP(scorpio):
> > > rename(/var/spool/mail/dovecot-control/indexes/s/sc/scorpio/.Trash/dovecot.index.cache.lock,
> > >
> > > /var/spool/mail/dovecot-control/indexes/s/sc/scorpio/.Trash/dovecot.index.cache)
> > > failed: No such file or directory
> > > Sep 10
On Thu, 2008-09-11 at 11:11 +0300, Timo Sirainen wrote:
> > Sep 10 22:06:41 imap dovecot: IMAP(scorpio):
> > rename(/var/spool/mail/dovecot-control/indexes/s/sc/scorpio/.Trash/dovecot.index.cache.lock,
> >
> > /var/spool/mail/dovecot-control/indexes/s/sc/scorpio/.Trash/dovecot.index.cache)
> >
On Wed, 2008-09-10 at 22:49 +0200, Cor Bosman wrote:
> > Since it's copying related, try running two instances of imaptest where
> > one copies messages and another runs on the destination box:
> >
> > ./imaptest logout=0 copy=100 copybox=Trash
> > ./imaptest box=Trash append=0
>
> It took about
> Since it's copying related, try running two instances of imaptest where
> one copies messages and another runs on the destination box:
>
> ./imaptest logout=0 copy=100 copybox=Trash
> ./imaptest box=Trash append=0
It took about 1.5 hours, but I got 1..running the above 2 tests at the same
time.
on 9-10-2008 11:55 AM Cor Bosman spake the following:
./imaptest logout=0 copy=100 copybox=Trash
./imaptest box=Trash append=0
Ok, running those 2 now.
Still need dovecot -n?
I guess it could still show something useful. :)
# 1.1.2: /usr/local/etc/dovecot.conf
base_dir: /var/run/dovecot/
s
> ./imaptest logout=0 copy=100 copybox=Trash
> ./imaptest box=Trash append=0
Ok, running those 2 now.
> > Still need dovecot -n?
>
> I guess it could still show something useful. :)
# 1.1.2: /usr/local/etc/dovecot.conf
base_dir: /var/run/dovecot/
ssl_ca_file: /etc/ssl/certs/verisign.pem
ssl_cer
On Wed, 2008-09-10 at 09:42 +0200, Cor Bosman wrote:
> > > Neither can i..
> > >
> > > As a test I set 1 server up with local FS again, but with NFS=yes and
> > > mmap/fsync etc as if it's nfs index, and im getting the same errors.
> >
> > So you can reproduce it easily with imaptest? Could you
> > Sep 10 13:43:13 userimap7.xs4all.nl dovecot: IMAP(xx):
> > rename(/var/spool/mail/dovecot-control/indexes/c/co/xx/.Junk
> > E-mail/dovecot.index.cache.lock,
> > /var/spool/mail/dovecot-control/indexes/c/co/xx/.Junk
> > E-mail/dovecot.index.cache) failed: No such file or director
On Wed, 2008-09-10 at 14:10 +0200, Cor Bosman wrote:
> Ive been able to grab the dovecot.rawlog output of a few people with this
> problem.. basically this is what I see with all of them:
>
> Sep 10 13:43:13 userimap7.xs4all.nl dovecot: IMAP(xx):
> rename(/var/spool/mail/dovecot-control/index
> >> So this is Outlook and its Junk Email Filters auto-copying these
> >> messages...
>
> > Nah, thats coincidental, the target folder doesnt seem to matter.
>
> Ok, but what about the client - is this outlook specific?
I doubt it. It's just a COPY command.
Cor
On 9/10/2008 8:18 AM, Cor Bosman wrote:
>>> da56 UID COPY 11078 "Junk E-mail"
>> So this is Outlook and its Junk Email Filters auto-copying these messages...
> Nah, thats coincidental, the target folder doesnt seem to matter.
Ok, but what about the client - is this outlook specific?
--
Best r
> > da56 UID COPY 11078 "Junk E-mail"
>
> So this is Outlook and its Junk Email Filters auto-copying these messages...
Nah, thats coincidental, the target folder doesnt seem to matter.
Cor
On 9/10/2008 8:10 AM, Cor Bosman wrote:
> Ive been able to grab the dovecot.rawlog output of a few people with this
> problem.. basically this is what I see with all of them:
>
> Sep 10 13:43:13 userimap7.xs4all.nl dovecot: IMAP(xx):
> rename(/var/spool/mail/dovecot-control/indexes/c/co/x
Ive been able to grab the dovecot.rawlog output of a few people with this
problem.. basically this is what I see with all of them:
Sep 10 13:43:13 userimap7.xs4all.nl dovecot: IMAP(xx):
rename(/var/spool/mail/dovecot-control/indexes/c/co/xx/.Junk
E-mail/dovecot.index.cache.lock,
/var/sp
> > Neither can i..
> >
> > As a test I set 1 server up with local FS again, but with NFS=yes and
> > mmap/fsync etc as if it's nfs index, and im getting the same errors.
>
> So you can reproduce it easily with imaptest? Could you post your
> dovecot -n output so I could see if I can reproduce i
On Tue, 2008-09-09 at 23:07 +0200, Cor Bosman wrote:
> > I just tested on my kvm FreeBSD 7.0 installation. I can't reproduce it
> > there either with "imaptest logout=0".
>
> Neither can i..
>
> As a test I set 1 server up with local FS again, but with NFS=yes and
> mmap/fsync etc as if it's nfs
> I just tested on my kvm FreeBSD 7.0 installation. I can't reproduce it
> there either with "imaptest logout=0".
Neither can i..
As a test I set 1 server up with local FS again, but with NFS=yes and
mmap/fsync etc as if it's nfs index, and im getting the same errors.
So it doesnt seem related
On Tue, 2008-09-09 at 20:39 +0200, Cor Bosman wrote:
> > b) Some process is crashing and leaving stale dovecot.index.cache.lock
> > files lying around. But that'd have to be a .lock from another server,
> > because on the same server Dovecot checks to see if the PID exists and
> > if not it'll just
> Yes, although the error message could be changed to "locking timed out".
> But at least now the error shouldn't be visible to clients (other than
> small slowdowns due to the 2 second lock wait).
>
> Anyway, the real problem is one of:
>
> a) Dovecot is really locking dovecot.index.cache file f
On Tue, 2008-09-09 at 21:26 +0300, Timo Sirainen wrote:
> On Tue, 2008-09-09 at 20:20 +0200, Cor Bosman wrote:
> > Now im seeing these:
> >
> > Sep 9 19:28:25 userimap3 dovecot: IMAP(x): file_dotlock_create()
> > failed with index cache file
> > /var/spool/mail/dovecot-control/indexes/u/ul/
On Tue, 2008-09-09 at 20:20 +0200, Cor Bosman wrote:
> Now im seeing these:
>
> Sep 9 19:28:25 userimap3 dovecot: IMAP(x): file_dotlock_create() failed
> with index cache file
> /var/spool/mail/dovecot-control/indexes/u/ul/x/.Collega
> Coaching/dovecot.index.cache: Resource temporarily
Now im seeing these:
Sep 9 19:28:25 userimap3 dovecot: IMAP(x): file_dotlock_create() failed
with index cache file
/var/spool/mail/dovecot-control/indexes/u/ul/x/.Collega
Coaching/dovecot.index.cache: Resource temporarily unavailable
Is that any better?
Cor
On Sep 9, 2008, at 7:35 PM, Cor Bosman wrote:
Oh, now im getting assert failed with those 2 patches applied..
Sep 9 18:33:59 userimap3 dovecot: Panic: IMAP(x): file mail-
cache.c: line 572 (mail_cache_lock): assertion failed: ((ret <= 0
&& !cache->locked) || (ret > 0 && cache->locked))
* Cor Bosman <[EMAIL PROTECTED]>:
> Oh, now im getting assert failed with those 2 patches applied..
>
> Sep 9 18:33:59 userimap3 dovecot: Panic: IMAP(x): file mail-cache.c:
> line 572 (mail_cache_lock): assertion failed: ((ret <= 0 && !cache->locked)
> || (ret > 0 && cache->locked))
Same h
Oh, now im getting assert failed with those 2 patches applied..
Sep 9 18:33:59 userimap3 dovecot: Panic: IMAP(x): file mail-cache.c: line
572 (mail_cache_lock): assertion failed: ((ret <= 0 && !cache->locked) || (ret
> 0 && cache->locked))
Cor
> Did a couple of changes:
>
> http://hg.dovecot.org/dovecot-1.1/rev/898e3810c014
> http://hg.dovecot.org/dovecot-1.1/rev/e3c5acf92b53
Ok, will add them.
> You could check how large the dovecot.index.cache file is for those
> users. Normally it's something like 10-20% of the mailbox size, but it
On Tue, 2008-09-09 at 17:31 +0200, Cor Bosman wrote:
> > 60 seconds is also when Dovecot decides the dotlock file is stale. So I
> > guess the cache file compression is taking longer than that. Hmm. I
> > hadn't thought about that before, since it was supposed to happen rarely
> > enough. But I gue
> 60 seconds is also when Dovecot decides the dotlock file is stale. So I
> guess the cache file compression is taking longer than that. Hmm. I
> hadn't thought about that before, since it was supposed to happen rarely
> enough. But I guess during the compression other processes shouldn't be
> stuc
On Tue, 2008-09-09 at 17:16 +0200, Cor Bosman wrote:
> Oops, I do see a logline, just not in the error log. Weird.
>
> Sep 9 16:42:54 userimap3.xs4all.nl dovecot: IMAP(xxx):
> rename(/var/spool/mail/dovecot-control/indexes/d/dr/xxx/.Trash/dovecot.index.cache.lock,
>
> /var/spool/mail/d
Oops, I do see a logline, just not in the error log. Weird.
Sep 9 16:42:54 userimap3.xs4all.nl dovecot: IMAP(xxx):
rename(/var/spool/mail/dovecot-control/indexes/d/dr/xxx/.Trash/dovecot.index.cache.lock,
/var/spool/mail/dovecot-control/indexes/d/dr/xxx/.Trash/dovecot.index.cache)
> If copying a single mail takes longer than the dotlocking timeout,
> another process may have overridden the lock file and caused errors.
> And since it took so long, maybe PHP or something timed out.
>
> This should help figuring out if the problem is due to timeouts:
> http://hg.dovecot.or
> >They often say it took a while to get the error, and some people are
> >suggesting it's only with large emails. So it could be a PHP timeout
> >related bug, although im not positive.
> >
> >I dont think it's a coincidence that every single person that
> >complaints
> >has that set of errors in
On Sep 8, 2008, at 11:28 PM, Cor Bosman wrote:
They often say it took a while to get the error, and some people are
suggesting it's only with large emails. So it could be a PHP timeout
related bug, although im not positive.
I dont think it's a coincidence that every single person that
complai
> > Ive been getting a LOT of these errors since 1.1.2:
>
> What version did you use before?
I used 1.1-rc4 -> 1.1.1 -> 1.1.2
> > So far ive seen this
> > with 1800 customers, and we're getting active complaints about errors in
> > imap clients. When I check the users log I always see this err
On Mon, 2008-09-08 at 17:40 +0200, Cor Bosman wrote:
> Ive been getting a LOT of these errors since 1.1.2:
What version did you use before?
> So far ive seen this
> with 1800 customers, and we're getting active complaints about errors in
> imap clients. When I check the users log I always see t
Ive been getting a LOT of these errors since 1.1.2: So far ive seen this
with 1800 customers, and we're getting active complaints about errors in
imap clients. When I check the users log I always see this error..
This always happens with COPY commands in Squirrelmail.
Sep 2 20:09:35 userimap4.x
41 matches
Mail list logo
