Running Dovecot

Starting

Dovecot can simply be started by running dovecot as root. If there are any problems, they're usually written to terminal, but they may also be written to error log at page logging as well.

• See startup scripts

Reloading

The configuration is reloaded with doveadm reload. The internal processes (config, stats, auth, dict, ...) are always replaced by the reload. What happens to the processes that are serving clients is decided by service_shutdown_clients_timeout:

Value	Description
0	The default. The clients are disconnected immediately.
time	The clients keep their sessions for this long.
infinite	The clients are never disconnected.

This makes it possible to take a new SSL certificate into use without disconnecting anyone:

service_shutdown_clients_timeout = 4h

doveadm reload

New connections use the new certificate immediately, while the sessions that were open during the reload keep running - at most for four hours, after which they are disconnected. The setting can also be set per service, e.g. service pop3 { shutdown_clients_timeout = 0 } disconnects the POP3 sessions immediately regardless of the value set outside the service.

The time is the maximum: when it is up, the processes disconnect all their remaining clients, also the ones that are in the middle of a command, and the login processes abort the logins that are still in progress. A login process that proxies a connection to a backend waits up to two seconds for the connection to become quiet, so that a reply isn't cut in the middle.

Both processes serving a session need the timeout: with TLS the login process keeps proxying the connection also after the login, so the session ends as soon as either of the imap and imap-login processes is killed. On a proxy there are no local imap processes - the login processes proxy the connections to the backends - so the login service's timeout alone decides how long the existing sessions keep running.

A single reload can override the setting for all the services with doveadm reload --kick-timeout. The override covers also the processes that earlier reloads left running, so --kick-timeout 0 disconnects every preserved client.

The preserved processes are visible in doveadm process status. Its generation column increases by one for every reload, so the preserved processes have a smaller number than the current generation, and its kill_time column tells when the master is going to disconnect their clients. doveadm service status lists only the current generation, unless it's given the -a parameter.

Note that the preserved processes keep using the old configuration for as long as they live, including the old passdb/userdb and mail settings.

Stopping

Killing the Dovecot master process with a normal TERM signal does a clean shutdown. This can be done easily with doveadm stop.

service_shutdown_clients_timeout also controls how long existing IMAP and POP3 sessions are kept alive after the master process is gone. Note that there is nobody left to escalate to SIGKILL, so the processes stop themselves at the deadline.

If you are using systemd, you need to set:

[Service]
KillMode=none
ExecStop=/usr/bin/doveadm stop

to avoid systemd from killing processes on restart.

Processes

When Dovecot is running, it uses several processes:

ps auxw|grep "dovecot"

root        7245  0.1  0.1   2308  1096 pts/0    S+   19:53   0:00 dovecot
dovecot     7246  0.0  0.0   2084   824 pts/0    S+   19:53   0:00 dovecot/anvil
root        7247  0.0  0.0   2044   908 pts/0    S+   19:53   0:00 dovecot/log
root        7250  0.0  0.3   4988  3740 pts/0    S+   19:53   0:00 dovecot/config
root        7251  0.0  0.2  10024  2672 pts/0    S+   19:53   0:00 dovecot/auth
root        7303  0.6  0.3  10180  3116 pts/0    S+   19:57   0:00 dovecot/auth -w
vmail       7252  0.0  0.1   3180  1264 pts/0    S+   19:53   0:00 dovecot/imap
vmail       7255  0.0  0.1   3228  1596 pts/0    S+   19:54   0:00 dovecot/pop3
dovenull    7260  0.0  0.1   4028  1940 pts/0    S+   19:54   0:00 dovecot/imap-login
dovenull    7262  0.0  0.1   4016  1916 pts/0    S+   19:54   0:00 dovecot/pop3-login

• dovecot process is the Dovecot master process which keeps everything running.
• anvil keeps track of user connections.
• log writes to log files. All logging, except from master process, goes through it.
• config parses the configuration file and sends the configuration to other processes.
• auth handles all authentication.
• auth -w process is an authentication worker process. It's used only with some "blocking" authentication databases, such as SQL authentication database.
• imap-login and pop3-login processes handle new IMAP and POP3 connections until user has logged in. They also handle proxying SSL connections even after login.
• imap and pop3 processes handle the IMAP and POP3 connections after user has logged in.

Reloading Configuration

Sending HUP signal to Dovecot reloads configuration. This can be done easily with: doveadm reload. An acknowledgement is written to log file.

Running Multiple Invocations of Dovecot

You may wish to invoke a second session (or even multiple sessions) of Dovecot for testing different functionality, configurations, etc.

In order to run multiple instances of Dovecot, you must:

1. Create a differently named copy of the dovecot.conf configuration file with these changes:

   1. Change base_dir to the new run directory.

   2. Change services' inet_listener port numbers to new, unused values.

   3. Optionally, change instance_name to show a different "dovecot/" prefix in ps output.

   4. If you're using authentication sockets (for SMTP AUTH or deliver), you'll need to change them as well. auth_socket_path specifies the socket path for deliver.

      • Alternatively, if all the instances have identical authentication configuration, you can have only a single Dovecot instance serve the auth sockets and have the other instances use them.

2. Invoke dovecot (and dovecot-lda) with the -c parameter and the modified configuration file, e.g.: dovecot -c /usr/local/etc/dovecot2.conf

3. In order to tell the logs apart, you can set different log facilities for the instances, e.g., syslog_facility=local6, then configure syslogd to write local6 into "dovecot-otherinstance.log". Alternatively specify the log paths directly in log_path and related settings.

Rotating Log Files

If you specified log file paths manually in dovecot.conf instead of using syslog, you can send USR1 signal to Dovecot to make it close and reopen the log files. This can be done with: doveadm log reopen.

Troubleshooting

If you can't see the Dovecot processes running after starting dovecot, something is most likely wrong in your dovecot.conf. Look at the error from Dovecot's log file. See logging for how to find the log.

If you really can't find any error messages from any logs, try starting Dovecot with dovecot -F. If you see it crash like:

sh: segmentation fault (core dumped) dovecot -F

Then it's a bug in Dovecot. Please report it with your configuration file.

If it simply quits without giving any error, then it wrote the error to a log file and you just didn't find it. Try specifying the log file manually and make sure you're really looking at the correct file.

See also Dovecot troubleshooting.