Hi,
I recently upgraded dovecot on an OpenBSD server from the 0.99.x series to the 1.0-test series to eliminate a problem. That was fixed, however I am now experiencing issues with IMAP(S) connections. The main IMAPS use to the server is via Squirrelmail (many users login with it), however I typically use Thunderbird. The user mailboxes are stored in Maildir format.
Basically, moving, deleting or copying mails tends not to work. I have managed to move mails in Thunderbird if the source mailbox is small, and deleting mails usually works in Thunderbird. However, in Squirrelmail deleting or moving results in:
"ERROR : Connection dropped by imap-server. Query: COPY 5629 "<dest-mailbox>"
/var/log/maillog reports: May 24 23:19:03 orca dovecot: IMAP(jmcaree): pool_system_malloc(): Out of memory
The Out of memory error appears when moving mails with Thunderbird, also.
I had originally upgraded to dovecot1.0-test66 via a patch supplied by an OpenBSD porter. Today I decided to compile -test70 to see if it was any better. Unfortunately, this issue still exists. I tried upgrading Squirrelmail to the latest (1.4.4 from 1.4.3a), but no luck there. Since it's happening with both it and Thunderbird, though, I don't see it being a client issue.
Server is: # uname -a OpenBSD my.hostname.com 3.7 GENERIC.RAID#0 amd64
I'd appreciate any assistance or advice on this issue! Obviously, I'd prefer to not have to downgrade to the 0.99.x series. :-) I'm not subscribed to the list, so please CC me with any replies.
TIA,
John.
On Tue, 2005-05-24 at 23:33 +0100, John McAree wrote:
Basically, moving, deleting or copying mails tends not to work. I have managed to move mails in Thunderbird if the source mailbox is small, and deleting mails usually works in Thunderbird. However, in Squirrelmail deleting or moving results in:
"ERROR : Connection dropped by imap-server. Query: COPY 5629 "<dest-mailbox>"
/var/log/maillog reports: May 24 23:19:03 orca dovecot: IMAP(jmcaree): pool_system_malloc(): Out of memory
The Out of memory error appears when moving mails with Thunderbird, also.
Sounds a bit strange that those would eat so much memory. Have to look into it.. How large are the mailboxes where it happens?
Anyway, you could disable the memory limit by setting mail_process_size = 0. The default is 256MB which should have been enough for pretty huge mailboxes.
Also if it works after that change, could you tell me how large the imap process becomes?
Hello John,
- John McAree <john@mcaree.org> [2005-05-24 23:33:00 +0100]:
/var/log/maillog reports: May 24 23:19:03 orca dovecot: IMAP(jmcaree): pool_system_malloc(): Out of memory
I'd suggest to check the value of mmap_no_write option in dovecot.conf as it disables the use of memory mapping, which is required in OpenBSD environments.
# Don't write() to mmaped files. This is required for some operating systems # which use separate caches for them, such as OpenBSD. mmap_no_write = no
I'm not sure whether this helps, but this is the first thing that came to my mind that would be related to this.
Thanks, Tero
-- Tero Ripattila
On Wed, 2005-05-25 at 10:17 +0300, Tero Ripattila wrote:
/var/log/maillog reports: May 24 23:19:03 orca dovecot: IMAP(jmcaree): pool_system_malloc(): Out of memory
I'd suggest to check the value of mmap_no_write option in dovecot.conf as it disables the use of memory mapping, which is required in OpenBSD environments.
Oh, you're using mmap_no_write=yes and mmap_disable=no? That could explain the problems with test70 you're experiencing. I forgot there was a separate mmap_no_write=yes setting :)
And BTW. you're the one originating those Someone's Name <dovecot@dovecot.org> To-headers? They're pretty confusing.
Hello Timo,
On Wed, May 25, 2005 15:05, Timo Sirainen said:
Oh, you're using mmap_no_write=yes and mmap_disable=no? That could explain the problems with test70 you're experiencing. I forgot there was a separate mmap_no_write=yes setting :)
No, that's what I should have according to common sense, IMO, but I just noticed that I actually have it like this:
#mmap_disable = no and mmap_no_write = no
where as I should have set the last option to yes.
What's the correct way to set these two options?-) *grin*
Thanks, Tero
-- Tero Ripattila
On Wed, 2005-05-25 at 17:23 +0300, Tero Ripattila wrote:
No, that's what I should have according to common sense, IMO, but I just noticed that I actually have it like this:
#mmap_disable = no and mmap_no_write = no
where as I should have set the last option to yes.
What's the correct way to set these two options?-) *grin*
I see, that makes even more sense now why it's broken with you. :)
mmap_no_write=yes is needed for OpenBSD, which is pretty much the only UNIX kernel left where mmap() and write() conflict with each others and makes things a mess. This is the default when compiled for OpenBSD, so you just shouldn't have uncommented the line and everything should have worked.
mmap_disable=yes is for completely disabling mmap()ing, and also introduces some other changes to allow shared filesystems to work (NFS, clustered filesystems, etc.)
Hello Timo,
--On 25. toukokuuta 2005 17:39 +0300 Timo Sirainen <tss@iki.fi> wrote:
I see, that makes even more sense now why it's broken with you. :)
mmap_no_write=yes is needed for OpenBSD, which is pretty much the only UNIX kernel left where mmap() and write() conflict with each others and makes things a mess. This is the default when compiled for OpenBSD, so you just shouldn't have uncommented the line and everything should have worked.
mmap_disable=yes is for completely disabling mmap()ing, and also introduces some other changes to allow shared filesystems to work (NFS, clustered filesystems, etc.)
Okay, now I've got both set to yes ;-) I really hope that this finally works like it used to :-)
-- Tero Ripattila
Hello Timo,
Wednesday, May 25, 2005, 5:39:43 PM, you [TS] wrote:
TS> I see, that makes even more sense now why it's broken with you. :)
TS> mmap_no_write=yes is needed for OpenBSD TS> mmap_disable=yes is for completely disabling mmap()ing
I still get core dumps, but not that often than before the configuration option change I did. Will have now a further look of this and then send you some back traces when I find what triggers this.
Thanks, Tero
-- Tero Ripattila
Hi,
Thanks to Tero and Timo for the quick replies!
Tero Ripattila wrote:
I'd suggest to check the value of mmap_no_write option in dovecot.conf as it disables the use of memory mapping, which is required in OpenBSD environments.
# Don't write() to mmaped files. This is required for some operating systems # which use separate caches for them, such as OpenBSD. mmap_no_write = no
This is set to yes, so it's not a problem with that, but thanks anyway.
I followed Timo's suggestion of setting mail_process_size = 0. After restarting dovecot, there is no change. I have noticed, however, that in Thunderbird my mails that it identifies as spam are moved automatically to my spam folder. Moving anything manually (by dragging, or by right-clicking and using the Move-To menu) still does not work. And Squirrelmail is still erroring out. :(
My mailbox sizes vary, but my main INBOX currently has 1643 mails in it. I just tried moving a message from a mailbox with 289 messages in it, to another with 264: May 25 19:11:23 orca dovecot: IMAP(jmcaree): pool_system_malloc(): Out of memory May 25 19:11:23 orca dovecot: child 28450 (imap) returned error 83 (Out of memory)
So again, even with smaller mailboxes there are issues.
John.
participants (3)
-
John McAree
-
Tero Ripattila
-
Timo Sirainen