dovecot - Jun 2021 - 2.3.14: stale imap-login processes due to bogus user setup tying up process limit

I just dealt with an interesting Dovecot issue on our small server, and thought
I might share it. I also feel that although in the end it was a configuration
error, Dovecot should somehow avoid leaving this processes around and hence
filling up the process limit quickly.

- set up Dovecot IMAP on Debian buster (either with the older 2.3.x Debian
package, or 2.3.14 from the dovecot-repo)
- config:
...
namespace inbox {
  inbox = yes
  location = 
  ... default settings ...
...
passdb {
  args = scheme=HMAC-MD5 username_format=%u /etc/dovecot/users
  driver = passwd-file
}
protocols = " imap"
...
userdb {
  args = blocking=no
  driver = passwd
}
...
- secret sauce: have a user in the passdb that doesn't have a physical
account on the system yet (we were migrating to a new machine).

The log-file shows successful authentication for that user (after we flipped DNS
to point to this new machine), but over time (2-3 times/day) we were left with
an increasing number of `imap-login` processes in state `pre-login`, eventually
requiring a dovecot restart. Dialling up process_limits didn't seem to help,
we'd just get more of these stale processes.

After creating the user on the system, the behaviour reverted to normal, no more
stale processes. I do not know what error message that user received on their
end, but since we announced we were migrating, they probably just ignored it and
thought it as part of the transition.

Best,
   Volker (a happy & long Dovecot user)

> On 01/06/2021 10:59 Volker Stolz <vs at foldr.org> wrote:
> 
>  
> I just dealt with an interesting Dovecot issue on our small server, and
thought I might share it. I also feel that although in the end it was a
configuration error, Dovecot should somehow avoid leaving this processes around
and hence filling up the process limit quickly.
> 
> - set up Dovecot IMAP on Debian buster (either with the older 2.3.x Debian
package, or 2.3.14 from the dovecot-repo)
> - config:
> ...
> namespace inbox {
>   inbox = yes
>   location = 
>   ... default settings ...
> ...
> passdb {
>   args = scheme=HMAC-MD5 username_format=%u /etc/dovecot/users
>   driver = passwd-file
> }
> protocols = " imap"
> ...
> userdb {
>   args = blocking=no
>   driver = passwd
> }
> ...
> - secret sauce: have a user in the passdb that doesn't have a physical
account on the system yet (we were migrating to a new machine).
> 
> The log-file shows successful authentication for that user (after we
flipped DNS to point to this new machine), but over time (2-3 times/day) we were
left with an increasing number of `imap-login` processes in state `pre-login`,
eventually requiring a dovecot restart. Dialling up process_limits didn't
seem to help, we'd just get more of these stale processes.
> 
> After creating the user on the system, the behaviour reverted to normal, no
more stale processes. I do not know what error message that user received on
their end, but since we announced we were migrating, they probably just ignored
it and thought it as part of the transition.
> 
> Best,
>    Volker (a happy & long Dovecot user)
Hi Volker,

can you please post full `doveconf -n` output, please?

Aki

Hello!

We've had this same thing happening on our dovecot install.  Now and
then the imap server stops accepting connections because of the number
of imap-login processes.  The process_limit for imap-login is set to
1024.  Restarting dovecot clears it up for a while.

I turned on verbose_proctitle, and found that the stale processes all
say "pre-login".  The start times all coincide with an invalid login
attempt to the IMAP server.

We are using LDAP as our userdb.

We are using dovecot-imapd version 1:2.3.13+dfsg1-2 on Debian bullseye.

We also had this same thing happen years ago with a similar setup.  I
never got around to investigating it as much, so I don't know if it's
exactly the same, but it did show a bunch of extra imap-login
processes, and we would clear it up by restarting dovecot.

Should I file a bug report?

Thanks!
Chad.