More of my users are accessing mail remotely, which probably explained why I started seeing
Mar 18 05:50:34 dovecot: master: Warning: service(imap-login):
process_limit (2) reached, client connections are being droppedI played around with increasing limits, but made the mistake of setting service_count to a value other than 0 and 1.
service imap-login {
client_limit = 1024
service_count = 10240
process_min_avail = 2
process_limit = 8
}Doubling and redoubling process_limit and increasing service_count didn't prevent IMAP from eventually grinding to a halt because process_limit was reached.
Mar 18 12:36:12 dovecot: master: Warning: service(imap-login):
process_limit (4) reached, client connections are being dropped
Mar 18 20:39:48 viol dovecot: master: Warning: service(imap-login):
process_limit (8) reached, client connections are being droppedObserving the way imap-login processes spawn and retain file descriptors, I finally understood the subtlety of [1], which explains that imap-login will not exit despite reaching service_count if one SSL connection is still open.
With many long-lived client connections, the asymptotic behaviour is that the total #clients plateaus, but get spread out over many imap-login processes, with many lingering on to hold a few SSL connections. For service_count>1, process_limit should be set to a large fraction of peak simultaneous clients (i.e. the same value used when service_count=1), otherwise there is a high likelihood of running into process_limit and game over.
Given this behaviour, there doesn't seem much sense in setting service_count to anything but 0 (unlimited => performance mode) or 1 (security mode). Setting to other values supposedly limit memory leaks, but if a single persistent SSL client can hold up an imap-login process from exiting and releasing memory, it seems to negate this purpose.
Anyways, maybe [1] can mention this so others don't fall into the same pit I did.
References [1] https://doc.dovecot.org/admin_manual/login_processes/
Joseph Tam jtam.home@gmail.com