Hitting process limit for imap-login


#1

I started having problems over the weekend. I noticed that mail wasn’t being delivered and when I checked for mail, the app was just spinning. When I logged in to the admin console most of the services were not online. I restarted my droplet (DigitalOcean) and the services came back online.

Then it happened again on Tuesday, and I ran sudo mailinabox and the services restarted. It happened again yesterday, and sudo mailinabox restarted the services again.

This time, I had time to dig into the problem and noticed the logs were reporting a process limit had been reached for dovecot/imap-login. I restarted dovecot with service dovecot restart and was able to check mail again. But I already see logins stacking up:

root@mailbox:/var/log# ps -ef | grep login
root       917     1  0 May09 ?        00:00:00 /lib/systemd/systemd-logind
dovenull 26802 26760  0 08:32 ?        00:00:00 dovecot/imap-login
dovenull 26804 26760  0 08:32 ?        00:00:00 dovecot/imap-login
dovenull 26811 26760  0 08:32 ?        00:00:00 dovecot/imap-login
dovenull 26815 26760  0 08:32 ?        00:00:00 dovecot/imap-login
dovenull 26818 26760  0 08:32 ?        00:00:00 dovecot/imap-login
dovenull 26820 26760  0 08:33 ?        00:00:00 dovecot/imap-login
dovenull 26831 26760  0 08:33 ?        00:00:00 dovecot/imap-login

I’m running a basic DigitalOcean droplet with 1GB of memory and 25GB of disk. It’s not hitting any of those limits (though the resources are at about 80%, and I’m resizing the droplet now to the newer, more robust $10 version they came out with a few months back).

Any solution to this other than cronning up a reset of the dovecot service once an hour or something?


#2

I would take a look and see how many devices are logging in using the affected account.


#3

Not too many. We have about 5 users in total. Each of them has a smartphone/desktops, but nobody is doing anything out of the ordinary.


#4

No accounts compromised??


#5

Not that I can see. Nothing nefarious-looking in the logs.

The droplet finished resizing and it’s now bumped up to 2GB of memory and 50GB of space, which is twice as much as before. It seems happy so far; only time will tell if this lasts.


#6

If the problem occurs again, check if Digital Ocean has some problems on your cluster. 5 users should not be the problem. If the storage fails / slow response, you can get this kind of behaviour. The other thing, i should check is the amount of connections with - for example - netstat

But even if Digital Ocean has problems and the system restores, the response should become “normal”.

Good luck with debugging.


#7

Reporting in (in case anyone is interested) that the problems have essentially vanished since upgrading my droplet. I’m not sure if it was resource-starved, or what. But a bit more memory and disk and there have been no issues since.