[Dovecot] "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@svanberg.no [*Takapa@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).
- Timo Sirainen tss@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@svanberg.no [*Takapa@IRC (EFnet)]
- Vegard Svanberg vegard@svanberg.no [2009-02-13 19:33]:
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:
Just noticed the changelog for 1.1.5. I'll file a bug against the Ubuntu package and ask the maintainer to build a package of the latest version. It seems this problem has already been fixed.
-- Vegard Svanberg vegard@svanberg.no [*Takapa@IRC (EFnet)]
participants (2)
-
Timo Sirainen
-
Vegard Svanberg