I encountered this error on FreeBSD 9.3 with dovecot2-2.2.13_3
Short version; vsz_limit is 18,447 PB and it ran out of RAM. Suggestions for
change?
Sep 6 03:39:32 mailjail dovecot: imap(dan): Panic: file imap-fetch.c: line 556
(imap_fetch_more): assertion failed: (ctx->client->output_cmd_lock == NULL
|| ctx->client->output_cmd_lock == cmd)
Sep 6 03:39:32 mailjail dovecot: imap(dan): Fatal: master: service(imap): child
71153 killed with signal 6 (core not dumped - set service imap {
drop_priv_before_exec=yes })
Sep 6 03:59:41 mailjail dovecot: imap(dan): Fatal:
pool_system_realloc(2097152): Out of memory
Sep 6 03:59:41 mailjail dovecot: imap(dan): Fatal: master: service(imap): child
67732 returned error 83 (Out of memory (service imap { vsz_limit=256 MB }, you
may need to increase it) - set CORE_OUTOFMEM=1 environment to get core dump)
Background: I?m in the only user on this system, but this server is accessed by
my phone, my laptop, my tablet, and perhaps a web interface.
Here are the non-default values:
$ doveconf -n
# 2.2.13: /usr/local/etc/dovecot/dovecot.conf
# OS: FreeBSD 9.3-RELEASE amd64
auth_mechanisms = plain login
first_valid_gid = 1001
first_valid_uid = 1001
mail_location = maildir:~/Maildir
mail_max_userip_connections = 80
mail_privileged_group = mail
passdb {
args = scheme=SHA512-CRYPT /var/db/dovecot.users
driver = passwd-file
}
protocols = imap
service imap-login {
inet_listener imap {
address = 10.0.0.1
}
inet_listener imaps {
port = 0
}
}
ssl = required
ssl_ca = </usr/local/etc/ssl/ca.pem
ssl_cert = </usr/local/etc/ssl/server.pem
ssl_key = </usr/local/etc/ssl/mailjail.example.org.nopassword.key
userdb {
args = /var/db/dovecot.users
driver = passwd-file
}
verbose_proctitle = yes
verbose_ssl = yes
But there are some interesting values when I look at the output of doveconf.
Specifically, vsz_limit is 18,447 PB? yeah, that?s pretty big.
service imap-login {
chroot = login
client_limit = 0
drop_priv_before_exec = no
executable = imap-login
extra_groups =
group =
idle_kill = 0
inet_listener imap {
address = 10.0.0.1
port = 143
reuse_port = no
ssl = no
}
inet_listener imaps {
address =
port = 0
reuse_port = no
ssl = yes
}
privileged_group =
process_limit = 0
process_min_avail = 0
protocol = imap
service_count = 1
type = login
user = $default_login_user
vsz_limit = 18446744073709551615 B
}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 333 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20140906/468756f2/attachment.sig>
On 6.9.2014 22:38, Dan Langille wrote:> I encountered this error on FreeBSD 9.3 with dovecot2-2.2.13_3 > > Short version; vsz_limit is 18,447 PB and it ran out of RAM. Suggestions for change? > > Sep 6 03:39:32 mailjail dovecot: imap(dan): Panic: file imap-fetch.c: line 556 (imap_fetch_more): assertion failed: (ctx->client->output_cmd_lock == NULL || ctx->client->output_cmd_lock == cmd) > Sep 6 03:39:32 mailjail dovecot: imap(dan): Fatal: master: service(imap): child 71153 killed with signal 6 (core not dumped - set service imap { drop_priv_before_exec=yes }) > Sep 6 03:59:41 mailjail dovecot: imap(dan): Fatal: pool_system_realloc(2097152): Out of memory > Sep 6 03:59:41 mailjail dovecot: imap(dan): Fatal: master: service(imap): child 67732 returned error 83 (Out of memory (service imap { vsz_limit=256 MB }, you may need to increase it) - set CORE_OUTOFMEM=1 environment to get core dump) >Check the message again - it says vsz_limit=256MB> Background: I?m in the only user on this system, but this server is accessed by my phone, my laptop, my tablet, and perhaps a web interface. >> > But there are some interesting values when I look at the output of doveconf. Specifically, vsz_limit is 18,447 PB? yeah, that?s pretty big. > > service imap-login { > vsz_limit = 18446744073709551615 B > } >According to your log it was process "imap" what ran out of memory. You are showing configuration for imap-login - they are not the same thing, see http://wiki2.dovecot.org/Design/Processes Not sure if this behaviour is a bug or something that is to be expected when you run out of VSZ limit in imap process - that needs to be answered by someone more knowledgeable