Table of Contents
Problem Description
On a busy Dovecot email server you might encounter the following serious problem in the log file:
tail -f /var/log/mail.log | egrep -i "warning|no auth attempts|error" Aug 19 18:28:02 server dovecot: master: Warning: service(imap-login): process_limit (100) reached, client connections are being dropped Aug 19 18:28:56 server dovecot: master: Warning: Sent SIGKILL to 95 imap-login processes
Additional Symptoms
- Clients might be complaining about unreliable email services
- Sending email using Thunderbird might complain about not being able to save in Sent Items.
- If you’re using PRTG and you’re monitoring IMAP reliability, then you’ll see little reds often indicating downtime on the IMAP service
Issues to Consider
The issue is the default value for process_limit on a Ubuntu server (20.04) is 100. The solution clearly would be to raise that limit, but as a responsible network engineer and server administrator you first have to ask yourself a few cardinal questions, e.g.:
- Why is the limit being reached?
- What are the implications of just “raising the limit”?
- To what value should one raise the limit?
Let’s run over these questions.
Why is the limit being reached?
Two possible reasons why the limit being reached could be:
- You have a very busy mail server and it’s okay – you just need to fine tune the system
- You are under attack. In this case, raising the limit might buy you some time and calm clients while you find the source of the attack
What are the implications of just “raising the limit”?
The implications of raising the limit is your server’s resources will be utilized more heavily. Both CPU and RAM implications should be a consideration, and if you have a magnetic or slow disk you have to take that into consideration too. If you are scant on resources, this could be a real problem. In the case of resource scarcity, you need to increase the resources.
To what value should one raise the limit?
Fine tuning a busy or broken or under attack system is more an art than a skill. The keys are:
- Establish a baseline. What do you think it normal?
- Increase the limit on a semi-conservative basis. Increasing from 100 to 150 would be acceptable, increasing from 100 to 1000 would not.
- Re-evaluate the situation. Has the problem gone away? Has the RAM in use shot up? Is it less noisy?
Without the pre and post evaluation you are just taking a shot in the dark.
Solution
vi /etc/dovecot/conf.d/10-master.conf
or
vi /etc/dovecot.conf
Change
default_process_limit = 100
to
default_process_limit = 150
then
service dovecot restart