Please send bug reports to Dovecot mailing list. If it’s not an entirely obvious bug, people in the list might be able to help figure it out. Security related bugs should be reported to Dovecot’s YesWeHack program or directly to security@dovecot.org.

 

You can provide most of the system related information with dovecot-sysreport command available since v2.3.10. If you are using older version, you can get the tool from https://raw.githubusercontent.com/dovecot/core/master/src/util/dovecot-sysreport

 

You should mention in your bug report:

  • Dovecot configuration with Dovecot -n (Don’t send the whole dovecot.conf file, it’s way too large especially if you don’t remove the comments). And if its output doesn’t already show, specify also:
    • Dovecot version
    • Operating system or Linux distribution name
    • CPU architecture (x86 or something else?)
    • Filesystem you used (especially if you use NFS or not)
  • Some kind of description of what you were doing and with what IMAP client.
  • If the problem can be reproduced, it helps a lot if you can tell how. If it happens only with a specific mail, add it as attachment if possible. You can hide all the actual mail data from mboxes using mbox-anonymize.

 

Debugging crashes

Whenever Dovecot crashes, you see something like this in log file:

 

dovecot: Apr 23 11:16:05 Error: child 86116 (imap) killed with signal 11

 

No matter how that happened, it’s a bug and will be fixed if you can provide enough information on how it happened. Best way is to get backtrace from gdb, but the problem is that Dovecot doesn’t dump core files by default. You can solve this in a few ways:

 

Core Dumps

Bugreport Mail

  • Install systemd-coredump if possible, it has proven to be good at capturing core dumps for dovecot.
  • core dumps disabled: Run ulimit -c unlimited before starting Dovecot. If you start Dovecot using some script, note that they often override the limit.
    • Red Hat: echo ‘DAEMON_COREFILE_LIMIT=”unlimited”‘ >> /etc/sysconfig/dovecot
  • core not dumped:
    • Write permissions: The process dumping the core needs to be able to write to the core dump directory. Check where the core file should be written to and make sure it has enough write permissions.
      • If core doesn’t contain an absolute path, it’s relative to the process’s current directory. With imap/pop3 processes this means that the core is written to the user’s home directory. Make sure home is returned by userdb by setting mail_debug=yes and checking from the logs that the correct home directory is returned.
      • Linux: You can specify where core gets written, e.g.: echo “/var/core/core.%e.%p” > /proc/sys/kernel/core_pattern
        • Also the crashing process needs to have write permissions for it, use e.g.: chmod 1777 /var/core
        • You need to allow core dumps in systemd as well, use systemctl edit dovecot and add
          [Service]
          LimitCORE=infinity
      • FreeBSD: You can specify core location with kern.corefile sysctl.
    • Process is chrooted: chrooted processes like imap-login will try to write the core inside the chroot, even when core_pattern is an absolute path. See below how to disable chrooting for imap-login.
    • Kernel thinks process is setuid
      • Linux: Dovecot usually tells the kernel to dump the core anyway. Modern linux systems require running to enable this:
        sysctl -w fs.suid_dumpable=2
      • FreeBSD: sysctl kern.sugid_coredump=1
      • For some services you may be able to tell Dovecot to drop privileges before execv(), making the process non-setuid. Add to the necessary service(s) to dovecot.conf:
        service .. { drop_priv_before_exec = yes }
    • Core file already exists: If there already exists a core file with the same name, it’s not overwritten.
    • Out of disk space: If core files are written to their own filesystem, you may not notice if it runs out of disk space.
    • Core is too large: If ulimit -c wasn’t set to unlimited, maybe the core size limit was reached?
  • core dumped: Core file was successfully written! Now you’ll just need to find it. See below.

 

Talk IMAP Directly

You can run imap binary directly and talk IMAP protocol to it. For example:

# gdb --args /usr/local/libexec/dovecot/imap -u user@domain
...
(gdb) r
Starting program: /usr/local/libexec/dovecot/imap 
* PREAUTH [CAPABILITY IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND UNSELECT
LITERAL+ IDLE CHILDREN LISTEXT LIST-SUBSCRIBED] Logged in as user

Then start typing IMAP commands, eg: x select inbox, x fetch 1:* (flags envelope bodystructure), x fetch 1 body.peek[]. When it crashes, execute bt full command in gdb.

 

Debugging hangs

Check for a few seconds what system calls the process is doing. See ProcessTracing in Wiki for more information.

GDB backtrace can also be highly helpful, especially if process tracing doesn't show anything happening. Then it means Dovecot is in some infinite loop. You can get the backtrace by attaching GDB into the existing process:





gdb -p pid-of-hanging-process
..
(gdb) bt full
#0 cmd_select (client=0x808d800) at cmd-select.c:87
#1 0x0804d36a in client_handle_input (client=0x808d800) at client.c:306
#2 0x0804d439 in _client_input (context=0x808d800) at client.c:342
..
(gdb) quit

 

Client Traffic Sniffing

If a problem happens only with a specific client, the best way to figure out what’s happening is to find out what it’s actually talking to server. Some clients may provide logging on their own, or you can use some TCP traffic sniffer such as Wireshark or ngrep.

You can also use Dovecot’s rawlog utility to log the traffic. It works also with SSL/