Memory leak or misconfiguration: Repeated allocation of very large block

2015-10-24 Thread Sebastian Wolfgarten 
Dear all,

I am using Dovecot 2.2.19 and I keep on getting the following warnings in my 
mail.log file on FreeBSD 10:

Oct 24 10:45:28 server1 dovecot: imap: Error: GC Warning: Repeated allocation 
of very large block (appr. size 20480):
Oct 24 10:45:28 server1 dovecot: imap: Error:   May lead to memory leak and 
poor performance.

I am wondering whether this is a configuration issue (i.e. a mistake in my 
current config) or whether I am hitting a bug. What’s the best way of figuring 
this one out? I tried increasing the verbosity of the logs but it did not 
really provide me with further information.

Any ideas?

Here is my config:

--

[root@server1 ~]# dovecot -n
# 2.2.19: /usr/local/etc/dovecot/dovecot.conf
# Pigeonhole version 0.4.9 (357ac0a0e68b+)
# OS: FreeBSD 10.1-RELEASE amd64  zfs
auth_cache_size = 50 M
auth_mechanisms = plain login
default_vsz_limit = 512 M
disable_plaintext_auth = no
first_valid_uid = 1008
last_valid_uid = 1008
login_greeting = Ready.
mail_gid = 1008
mail_location = maildir:/var/mail/vdomains/%d/%n
mail_max_keyword_length = 128
mail_max_userip_connections = 20
mail_uid = 1008
maildir_stat_dirs = yes
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character 
vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy 
include variables body enotify environment mailbox date index ihave duplicate
passdb {
  args = /usr/local/etc/dovecot/dovecot-sql.conf
  driver = sql
}
passdb {
  args = /usr/local/etc/dovecot/dovecot-sql.conf
  driver = sql
}
plugin {
  sieve = ~/.dovecot.sieve
  sieve_dir = ~/sieve
}
postmaster_address = sebast...@wolfgarten.com
protocols = imap pop3 lmtp sieve
service auth {
  unix_listener /var/spool/postfix/private/auth {
group = vmail
mode = 0666
user = vmail
  }
  user = $default_internal_user
}
service imap-login {
  inet_listener imap {
port = 143
  }
  inet_listener imaps {
port = 993
ssl = yes
  }
  process_min_avail = 3
  service_count = 0
  vsz_limit = 512 M
}
service imap-postlogin {
  executable = script-login /usr/local/etc/popafter.sh
  user = $default_internal_user
}
service imap {
  executable = imap imap-postlogin
  process_limit = 1024
  vsz_limit = 512 M
}
service lmtp {
  unix_listener lmtp {
mode = 0666
  }
}
service managesieve-login {
  inet_listener sieve {
port = 4190
  }
}
service pop3-login {
  inet_listener pop3 {
port = 110
  }
  inet_listener pop3s {
port = 995
ssl = yes
  }
}
service pop3-postlogin {
  executable = script-login /usr/local/etc/popafter.sh
  user = $default_internal_user
}
service pop3 {
  executable = pop3 pop3-postlogin
  process_limit = 1024
}
ssl_ca = 

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Question about dovecot replication

2015-10-24 Thread Timo Sirainen 

> On 23 Oct 2015, at 15:51, Urban Loesch  wrote:
> 
> Hi,
> 
> last week I installed 2 servers with two dovecot nodes and replication in 
> active/active mode located in different datacenters.
> 
> Based on the howto from wiki "http://wiki2.dovecot.org/Replication"; it works 
> great.
> According to the wiki it is recomended to run "doveadm purge" on both systems 
> continously, because "doveadm purge" will not be replicated by the
> replication service. No problem so far.
> 
> But I have one doubt:
> is it also reccmended (for keeping maildata in sync) to run "doveadm 
> replicator replicate '*'" continously on both nodes?
> Or is it enough on only one node?
> 
> Or should I run "doveadm sync -A tcp:anotherhost.example.com" in regular 
> intervalls? Perhaps once a day on both nodes?

The replicator process iterates through all users periodically 
(replication_full_sync_interval setting) and does full replication for all of 
them. So there's no need to run either of those doveadm commands.

Re: Notify plugin doesn't send mailbox_create notifications

2015-10-24 Thread Timo Sirainen 
On 23 Oct 2015, at 20:46, Lukas Mika  wrote:
> 
> Hi there,
> 
> I'm running dovecot 2.2.13 on my debian jessie server.
> When installing my own dovecot plugin, I noticed that there are no
> notifications coming from the notify plugin.
> 
> I checked back with the mail_log plugin, but also this plugin doesn't
> log any notifications when a new mailbox is created; the mail is saved
> to the new inbox never the less.

I don't know about 2.2.13, but at least with 2.2.19 it works:

/usr/local/libexec/dovecot/imap -O -o mail_plugins=notify,mail_log -o 
plugin/mail_log_events=mailbox_create -o mail=maildir:~/Maildir -u tss
a create testing
imap(tss): Info: Mailbox created: testing

> 
> I ran dovecot 2.2.9 before on my Ubuntu Trusty (14.04) server, where
> with the same settings the plugins worked.
> 
> Can you reproduce this issue and does anybody know a fix to this?
> 
> Here are the relevant bits of my config:
> 20-lmtp.conf:
> protocol lmtp {
> mail_plugins).
>  mail_plugins = $mail_plugins sieve mail_log notify
> }
> 
> 10-logging.conf
> ...
> plugin {
>  mail_log_events = mailbox_create
>  mail_log_fields = uid box
> }
> ...
> 
> Cheers

Re: Memory leak or misconfiguration: Repeated allocation of very large block

2015-10-24 Thread Timo Sirainen 
On 24 Oct 2015, at 14:59, Sebastian Wolfgarten  wrote:
> 
> Dear all,
> 
> I am using Dovecot 2.2.19 and I keep on getting the following warnings in my 
> mail.log file on FreeBSD 10:
> 
> Oct 24 10:45:28 server1 dovecot: imap: Error: GC Warning: Repeated allocation 
> of very large block (appr. size 20480):
> Oct 24 10:45:28 server1 dovecot: imap: Error: May lead to memory leak 
> and poor performance.
> 
> I am wondering whether this is a configuration issue (i.e. a mistake in my 
> current config) or whether I am hitting a bug. What’s the best way of 
> figuring this one out? I tried increasing the verbosity of the logs but it 
> did not really provide me with further information.

I guess you have configured Dovecot --with-gc? I guess it's possible this is a 
bug, but it could just as well be a false alarm. In general I don't 
recommend/support --with-gc option (and I should probably just remove it 
altogether). The easiest and the most usable way of finding memory leaks is to 
run with valgrind (which must be done without-gc):

service imap {
  executable = /usr/bin/valgrind -q --show-reachable=yes --leak-check=full 
/usr/libexec/dovecot/imap
}

I'm not aware of any memory leaks right now.