Timo Sirainen wrote:
blocking=yes doesn't break anything with nss_ldap, since without blocking=yes it'll run in one process anyway. PAM works differently.
Thanks for clarifying that.
You're somehow mixing up these things. :) Probably because of the "blocking" naming, which actually does the opposite of what it's named..
Yes, thanks for explaining further -- I was completely reading blocking=yes backwards from what you had designed as you pointed out. I was reading it as an instruction to Dovecot what to do, not an explanation to Dovecot what the machine is already doing.
blocking=no pam, blocking=yes nss_ldap: No memory leaks leaks. Fixes nss_ldap problems. Each PAM lookup is done in a forked process. NSS lookups are done in auth worker processes, as described above. So again no lookup blocks others.
OK this seems like the perfect solution; in dovecot.conf terms for a setup such as mine (nothing in /etc/passwd, 100% LDAP lookups for homedir, password, /etc/nsswitch.conf "passwd: files ldap", etc.) this would then be:
passdb pam { args = cache_key=%u dovecot }
userdb passwd { args = blocking=yes }
This would not block/stall in the pipelines, not cause memory leaks (since underlying code is released each cycle), avoid/fix nss_ldap issues with file descriptor reuse.
Do I finally have a good understanding now? (thanks for taking the time to work it out)
-te
-- Troy Engel | Systems Engineer Fluid, Inc | http://www.fluid.com