dovecot - Feb 2009 - "failed to map segment from shared object: Cannot allocate memory"

>From /var/log/auth.log (Dovecot 1.1.4 on Ubuntu 8.10): 
Feb 10 08:29:06 home dovecot-auth: PAM unable to
dlopen(/lib/security/pam_ck_connector.so): libdbus-1.so.3: failed to map segment
from shared object: Cannot allocate memory
Feb 10 08:29:06 home dovecot-auth: PAM adding faulty module:
/lib/security/pam_ck_connector.so

English, please? :) Strangely, it seemed to disappear after increasing
login_processes_count, login_max_processes_count and/or
auth_worker_max_count.

-- 
Vegard Svanberg <vegard at svanberg.no> [*Takapa at IRC (EFnet)]

On Tue, 2009-02-10 at 09:52 +0100, Vegard Svanberg
wrote:
> >From /var/log/auth.log (Dovecot 1.1.4 on Ubuntu 8.10): 
> 
> Feb 10 08:29:06 home dovecot-auth: PAM unable to
dlopen(/lib/security/pam_ck_connector.so): libdbus-1.so.3: failed to map segment
from shared object: Cannot allocate memory
> Feb 10 08:29:06 home dovecot-auth: PAM adding faulty module:
/lib/security/pam_ck_connector.so
> 
> English, please? :) Strangely, it seemed to disappear after increasing
> login_processes_count, login_max_processes_count and/or
> auth_worker_max_count.
Seems like a PAM memory leak. You probably just delayed the error by
increasing auth_worker_max_count. The right fix is most likely to set
auth_worker_max_request_count to a non-zero value (maybe 10 or 100).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20090210/59a0475e/attachment-0002.bin>

* Timo Sirainen <tss at iki.fi> [2009-02-11 01:40]:
> > English, please? :) Strangely, it seemed to disappear after increasing
> > login_processes_count, login_max_processes_count and/or
> > auth_worker_max_count.
> 
> Seems like a PAM memory leak. You probably just delayed the error by
> increasing auth_worker_max_count. The right fix is most likely to set
> auth_worker_max_request_count to a non-zero value (maybe 10 or 100).
Thanks, seems that problem's gone. However, I'm having other issues.

Fir,st auth_debug_passwords doesn't seem to work. auth_debug is set to yes.
What does a logged line with passwords look like? It just says
"msg=Password:"
here, like this:

Feb 13 19:12:39 home dovecot: auth-worker(default): pam(vegardsv,127.0.0.1):
lookup service=imap
Feb 13 19:12:39 home dovecot: auth-worker(default): pam(vegardsv,127.0.0.1):
#1/1 style=1 msg=Password:
Feb 13 19:12:39 home dovecot: auth(default): client out:
FAIL^I1^Iuser=vegardsv^Itemp
Feb 13 19:12:39 home dovecot: imap-login: Aborted login (auth failed, 1
attempts): user=<vegardsv>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1,
secured

The reason I'm asking, is that Dovecot doesn't always let users in.
It's
totally random. Every 10th login or so fails. Nothing exciting in auth.log:

Feb 13 19:12:37 home dovecot-auth: pam_unix(imap:session): session opened for
user vegardsv by (uid=0)
Feb 13 19:12:37 home dovecot-auth: pam_unix(imap:session): session closed for
user vegardsv

# dovecot -n
# 1.1.4: /etc/dovecot/dovecot.conf
log_timestamp: %Y-%m-%d %H:%M:%S 
protocols: imap imaps pop3 pop3s
disable_plaintext_auth: no
login_dir: /var/run/dovecot/login
login_executable(default): /usr/lib/dovecot/imap-login
login_executable(imap): /usr/lib/dovecot/imap-login
login_executable(pop3): /usr/lib/dovecot/pop3-login
login_processes_count: 100
login_max_processes_count: 250
mail_debug: yes
mail_executable(default): /usr/lib/dovecot/imap
mail_executable(imap): /usr/lib/dovecot/imap
mail_executable(pop3): /usr/lib/dovecot/pop3
mail_plugin_dir(default): /usr/lib/dovecot/modules/imap
mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap
mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3
auth default:
  mechanisms: plain login
  verbose: yes
  debug: yes
  debug_passwords: yes
  worker_max_count: 180
  worker_max_request_count: 3
  passdb:
    driver: pam
    args: session=yes *
  userdb:
    driver: passwd

-- 
Vegard Svanberg <vegard at svanberg.no> [*Takapa at IRC (EFnet)]