I wondered for a while if I should do this before v1.0, but since there seem to be problems with some PAM/NSS users and this was way easier to implement than I realized, here it is: passdb pam and userdb passwd now support blocking=yes setting in their args.

For PAM the default has been to fork the dovecot-auth process and talk via a pipe to the main dovecot-auth. I've never really liked this approach, but didn't bother fixing it before. However it is also what has caused the bugs with nss_ldap, and maybe with other NSS backends too.

NSS lookups then have been done all in the same dovecot-auth process without any forking. This meant that if it got stuck (or delayed a bit in LDAP queries and such), the whole dovecot-auth got stuck and all authentication attempts got stuck.

With blocking=yes the lookups are handled in dovecot-auth worker processes. Earlier these workers have been used only with MySQL. Initially there is only a single worker process, but whenever dovecot-auth notices that there are no free workers while a new auth request comes, a new worker is created. auth_worker_max_count specifies the maximum number of those processes.

This blocking=yes will probably work great with NSS. With PAM I'm not so sure. Mostly because the worker never exits, it just does one PAM auth after another. I think usually PAM is used only once in a process, so there might be memory leaks and maybe other bugs.. Then again, maybe not. I'll add some auth_worker_max_requests setting which can be set to 1 if this is a problem.

Also for blocking=no case I added code to send KILL signal to PAM child processes which haven't replied for 2 minutes. With blocking=yes this condition can't be checked currently.

http://dovecot.org/list/dovecot-cvs/2007-February/007639.html http://dovecot.org/list/dovecot-cvs/2007-February/007642.html http://dovecot.org/list/dovecot-cvs/2007-February/007646.html