OpenLDAP service suffers weekly loss of communication - Suse

This is a discussion on OpenLDAP service suffers weekly loss of communication - Suse ; We are experiencing an issue whereby the OpenLDAP server seems to crash and cannot be contacted, about once a week. We must restart OpenLDAP in order to resume normal service. Our LDAP service forms the basis for our email services. ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: OpenLDAP service suffers weekly loss of communication

  1. OpenLDAP service suffers weekly loss of communication


    We are experiencing an issue whereby the OpenLDAP server seems to crash
    and cannot be contacted, about once a week. We must restart OpenLDAP in
    order to resume normal service. Our LDAP service forms the basis for our
    email services. Users report that they cannot log into their mail either
    via an IMAP client or the webmail interface we have.

    The server is not particularly busy at the time of the crashes, and we
    have tried numerous LDAP repairs.

    Here is the relevant section of the logs:

    Aug 13 09:39:00 mail saslauthd[5082]: pam_ldap: ldap_starttls_s: Can't
    contact LDAP server
    Aug 13 09:39:00 mail saslauthd[5082]: DEBUG: auth_pam: pam_authenticate
    failed: Authentication failure
    Aug 13 09:39:00 mail saslauthd[5082]: do_auth : auth failure:
    [user=db139a] [service=imap] [realm=] [mech=pam] [reason=PAM auth error]
    Aug 13 09:39:00 mail imap[11899]: badlogin: localhost [127.0.0.1]
    plaintext db139a SASL(-13): authentication failure: checkpass failed
    Aug 13 09:39:00 mail PAM-warn[5066]: function=[pam_sm_acct_mgmt]
    service=[imap] terminal=[] user=[db139a] ruser=[]
    rhost=[]

    We are using SLES9 SP4, with OpenLDAP version 2.2.24-4.25 for both the
    client and server.

    uname -a output:
    Linux hostname 2.6.5-7.311-bigsmp #1 SMP Mon Mar 10 13:12:16 UTC 2008
    i686 i686 i386 GNU/Linux

    Any ideas greatly appreciated.

    Mark

  2. Re: OpenLDAP service suffers weekly loss of communication

    Hi Mark

    I cant directly help you but I do remember LDAP issues coming up in the
    Cyrus newsgroup on andrew.cmu.edu

    Perhaps a browse through their archives or even posting a question might
    help. There are quite a few uni sysops with large Cyrus IMAP/LDAP
    installations active on that group.

    (andrew.cme.edu is where the Cyrus IMAP code is hosted)

    CHeers Bob

    Maccy wrote:
    >
    > We are experiencing an issue whereby the OpenLDAP server seems to crash
    > and cannot be contacted, about once a week. We must restart OpenLDAP in
    > order to resume normal service. Our LDAP service forms the basis for our
    > email services. Users report that they cannot log into their mail either
    > via an IMAP client or the webmail interface we have.
    >


  3. Re: OpenLDAP service suffers weekly loss of communication

    On Fri, 05 Sep 2008 14:08:22 +0100, Maccy wrote:

    > We are experiencing an issue whereby the OpenLDAP server seems to crash
    > and cannot be contacted, about once a week. We must restart OpenLDAP in
    > order to resume normal service. Our LDAP service forms the basis for our
    > email services. Users report that they cannot log into their mail either
    > via an IMAP client or the webmail interface we have.
    >
    > The server is not particularly busy at the time of the crashes, and we
    > have tried numerous LDAP repairs.
    >
    > Here is the relevant section of the logs:
    >
    > Aug 13 09:39:00 mail saslauthd[5082]: pam_ldap: ldap_starttls_s: Can't
    > contact LDAP server
    > Aug 13 09:39:00 mail saslauthd[5082]: DEBUG: auth_pam: pam_authenticate
    > failed: Authentication failure
    > Aug 13 09:39:00 mail saslauthd[5082]: do_auth : auth failure:
    > [user=db139a] [service=imap] [realm=] [mech=pam] [reason=PAM auth error]
    > Aug 13 09:39:00 mail imap[11899]: badlogin: localhost [127.0.0.1]
    > plaintext db139a SASL(-13): authentication failure: checkpass failed Aug
    > 13 09:39:00 mail PAM-warn[5066]: function=[pam_sm_acct_mgmt]
    > service=[imap] terminal=[] user=[db139a] ruser=[]
    > rhost=[]
    >
    > We are using SLES9 SP4, with OpenLDAP version 2.2.24-4.25 for both the
    > client and server.
    >
    > uname -a output:
    > Linux hostname 2.6.5-7.311-bigsmp #1 SMP Mon Mar 10 13:12:16 UTC 2008
    > i686 i686 i386 GNU/Linux
    >
    > Any ideas greatly appreciated.
    >
    > Mark


    Try running lsof -p on the slapd server process. pipe it into wc -l
    to count the open files. If you get around 1024 then the slapd process is
    running out of file handles. You can put a ulimit into the startup script
    to increase the open file limit, say ulimit -n 8192.

    You can also modify slapd.conf and set a timeout for inactive sessions.
    Suse desktops like to open lots of ldap sessions - gnome dbus, screen
    saver, nscd, etc - but never bother closing them. Having the server shut
    them down does no harm but increases the server reliability.

    Hope this helps.

    Frank Ranner

  4. Re: OpenLDAP service suffers weekly loss of communication

    Frank Ranner wrote:

    > Try running lsof -p on the slapd server process. pipe it into wc -l
    > to count the open files. If you get around 1024 then the slapd process is
    > running out of file handles. You can put a ulimit into the startup script
    > to increase the open file limit, say ulimit -n 8192.
    >
    > You can also modify slapd.conf and set a timeout for inactive sessions.
    > Suse desktops like to open lots of ldap sessions - gnome dbus, screen
    > saver, nscd, etc - but never bother closing them. Having the server shut
    > them down does no harm but increases the server reliability.
    >
    > Hope this helps.
    >
    > Frank Ranner


    Hi Frank,

    Thanks very much for the suggestions.

    When I checked, the amount of open files was hovering around 900, so
    conceivably slapd could have been baulking under the strain of a flurry
    of emails. I set idletimeout to 5 minutes and the number of open files
    now hovers around the 100 mark.

    Hopefully this is the issue gone away....but I won't know for a few days
    I guess.

    Cheers

    Mark

+ Reply to Thread