[Dovecot] dovecot-1.0-test8 / nfs / maildir / flags issues
Hi List,
While (bluntly) testing the prerelease version of dovecot on our
mailfarm (just for the webmail imap) we noticed some small problems:
While our OLD dovecot/imap drove the load to a maximum of 1 over a
day after running, the new dovecot/imap pushes it easily to 20. This is
mainly due to a LOT more disk activity. This is probably caused by the
fact we a) use indexes on disk and b) there are no indexes left. I hope
this will smooth out when most of the indexes are made.We notice some very strange "delete" flag things in our IMP webmail
system (working on a test environment to be more specific). The problem
is that if you mark some messages "deleted", a lot of messages that do
NOT have "deleted" flag are also in the deleted list. Since nothing
changed on the webmail, it must be in the way dovecot responds
different in the new version on certain requests.In the dotlocking code, it seems that dovecot uses time() for it's
internal locktime, and uses stat() to see if the file-time of the lock
is different. Since we use nfs there might be a time-difference on the
file creation and time() when our nfs gets "busy". This happens a lot
when the indexes are created for multiple users at the same time
resulting in a lot of:May 12 08:57:44 mf1 dovecot[3763]: imap(user@domain.tld): Our dotlock
file
/var/mail/mounted/d/do/domain.tld/user/Maildir/.INBOX/ dovecot.index.log.lock was modified (1084345063 vs 1084345062),
assuming it wasn't overridden
I am not completely sure if this interrupts imap traffic. I think this
MIGHT be solved by storing a stat() time as the locktime instead of a
time(), but this might be intentional.
- I patched dovecot to report its pid in syslog messages, in order to
find the "killed by signal X" where X are mostly 11 and 6 processes.
The pids reported do not show up in the rest of the log file, so these
may be "disconnected" sessions? It seems that the "old" version has the
same problem, and nobody really complained it was broken, so this isn't
a big issue.
To clarify our setup:
We use multiple mail-frontends running dovecot that are load-balanced
by a cisco load-balancer. We mount our mailstores from an active-active
backend cluster, both nodes export a big partition, and take over the
job of the other in case of a problem. This seems to go pretty smooth.
Our users are stored in a pgsql database. In our current setup, we run
a modified cvs version of dovecot from WAY back, to support nfs. The
backdraw is that we can't use the newer dovecot releases, since I
couldn't modify the source in the way I did it the first time (with a
LOT of help from Timo :P).
If anyone has some ideas on where to look and where to test in order to
get our problems more clear, I would be very grateful :)
Kind regards,
Maikel Verheijen Ladot Nederland BV.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Maikel Verheijen wrote:
| - We notice some very strange "delete" flag things in our IMP webmail | system (working on a test environment to be more specific). The problem | is that if you mark some messages "deleted", a lot of messages that do | NOT have "deleted" flag are also in the deleted list. Since nothing | changed on the webmail, it must be in the way dovecot responds | different in the new version on certain requests.
Webmail applications reply (in most cases, IMP included) on PHP imap code.
When reporting problems with webmail programs, it is thus relevant to note what version of PHP you are running, and on what platform (or even better, if you know it: what version of libc-client it has been linked against).
It may be that your brand-new IMP relies on a brand-new PHP linking against an old buggy version of libc-client.
libc-client is the core engine from UW-imap, which is also used in Pine, PHP and other projects.
~ - Jonas
- Jonas Smedegaard - idealist og Internet-arkitekt
- Tlf.: +45 40843136 Website: http://dr.jones.dk/
~ - Enden er nær: http://www.shibumi.org/eoti.htm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFAo01sn7DbMsAkQLgRAmEZAJ4tiyX+SSX71rszgRHtZdGxw9hUMACgnymW wmnUPq/04B+xJegDHWvjaco= =NVXL -----END PGP SIGNATURE-----
In this case the version of PHP-imap might not be so relevant...my Horde/IMP (-cvs) has also broken in the latest test releases but works fine with the older (semi) stable 0.99 releases. All my mail folders appear empty when displayed with IMP although the folder list is fine (and even the message count in each folder is correct).
I suspect the command which is not working is:
00000004 UID SORT (ARRIVAL) US-ASCII ALL
The very bottom paragraph at http://www.dovecot.org/bugreport.html gives some clues as to how to go about debugging this sort of problem, and would probably be handy in this case too :)
reuben
At 10:26 p.m. 13/05/2004, Jonas Smedegaard wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Maikel Verheijen wrote:
| - We notice some very strange "delete" flag things in our IMP webmail | system (working on a test environment to be more specific). The problem | is that if you mark some messages "deleted", a lot of messages that do | NOT have "deleted" flag are also in the deleted list. Since nothing | changed on the webmail, it must be in the way dovecot responds | different in the new version on certain requests.
Webmail applications reply (in most cases, IMP included) on PHP imap code.
When reporting problems with webmail programs, it is thus relevant to note what version of PHP you are running, and on what platform (or even better, if you know it: what version of libc-client it has been linked against).
It may be that your brand-new IMP relies on a brand-new PHP linking against an old buggy version of libc-client.
libc-client is the core engine from UW-imap, which is also used in Pine, PHP and other projects.
~ - Jonas
Hi Jonas,
Thank you for your swift response.
Webmail applications reply (in most cases, IMP included) on PHP imap code.
When reporting problems with webmail programs, it is thus relevant to note what version of PHP you are running, and on what platform (or even better, if you know it: what version of libc-client it has been linked against). Agreed, I could (and should) have provided more information on the imp environment.
- php 4.3.1
- linux kernel 2.4.20
- IMAP c-Client version 2001
It may be that your brand-new IMP relies on a brand-new PHP linking against an old buggy version of libc-client. The IMP hasn't changed. Just the imapd (dovecot) has been updated (and downgraded)
~ - Jonas
Kind regards,
Maikel Verheijen Ladot Nederland BV.
On 13.5.2004, at 12:34, Maikel Verheijen wrote:
While (bluntly) testing the prerelease version of dovecot on our
mailfarm (just for the webmail imap) we noticed some small problems:
Not very good idea at least until "1.0 alpha". I can still pretty
easily make it crash and complain about corrupt indexes.
- While our OLD dovecot/imap drove the load to a maximum of 1 over a
day after running, the new dovecot/imap pushes it easily to 20. This
is mainly due to a LOT more disk activity. This is probably caused by
the fact we a) use indexes on disk and b) there are no indexes left. I
hope this will smooth out when most of the indexes are made.
I think this is mostly because the 1.0-tests don't cache anything. The
index files contain only message UIDs and flags, everything else
requires opening and parsing the message file. I'll fix the caching
once other things seem to be working.
- We notice some very strange "delete" flag things in our IMP webmail
system (working on a test environment to be more specific). The
problem is that if you mark some messages "deleted", a lot of messages
that do NOT have "deleted" flag are also in the deleted list. Since
nothing changed on the webmail, it must be in the way dovecot responds
different in the new version on certain requests.
Hm.. I'm not sure about this. Maybe concurrent access breaks it
sometimes..
In the dotlocking code, it seems that dovecot uses time() for it's
internal locktime, and uses stat() to see if the file-time of the lock
is different. Since we use nfs there might be a time-difference on the
file creation and time() when our nfs gets "busy". This happens a lot
when the indexes are created for multiple users at the same time
resulting in a lot of:May 12 08:57:44 mf1 dovecot[3763]: imap(user@domain.tld): Our dotlock
file
/var/mail/mounted/d/do/domain.tld/user/Maildir/.INBOX/ dovecot.index.log.lock was modified (1084345063 vs 1084345062),
assuming it wasn't overriddenI am not completely sure if this interrupts imap traffic. I think this
MIGHT be solved by storing a stat() time as the locktime instead of a
time(), but this might be intentional.
It does store and compare stat() times for that check.. There was a bug
where Dovecot itself overwrote the lock file and caused that error, but
it was fixed in test8 already. Maybe there's other such problems.
- I patched dovecot to report its pid in syslog messages, in order to
find the "killed by signal X" where X are mostly 11 and 6 processes.
The pids reported do not show up in the rest of the log file, so these
may be "disconnected" sessions? It seems that the "old" version has
the same problem, and nobody really complained it was broken, so this
isn't a big issue.
What else should there be in log file about them? Killed by signal 11
means just that it crashed without any specific reason. Signal 6 is
abort(), that should write the error into log file.
On Thu, May 13, 2004 at 11:34:17AM +0200, Maikel Verheijen wrote:
- We notice some very strange "delete" flag things in our IMP webmail
system (working on a test environment to be more specific). The problem
is that if you mark some messages "deleted", a lot of messages that do
NOT have "deleted" flag are also in the deleted list. Since nothing
changed on the webmail, it must be in the way dovecot responds
different in the new version on certain requests.
I also have this problem with 0.99 and the python 'offlineimap' script.
I can't easily reproduce it, but sometimes whole mboxes decide to be deleted. I am trying to get an IMAP dump and see what is happening.
C.
charlie@rubberduck.com - Melbourne, Australia http://rubberduck.com/~yeled/ PGP: 0x14AA7941 || finger yeled@lazy.spodder.com
participants (5)
-
Charlie Allom
-
Jonas Smedegaard
-
Maikel Verheijen
-
Reuben Farrelly
-
Timo Sirainen