Description of problem:

If am-utils' amd is used with ldap, this one will keep opening connections and
not closing them. In fact, lsof shows 100's of established connections to the
ldap server from amd, yet amd scrolls:  "Unable to ldap_open to ldap_server:389"
in /var/log/messages.

RHEL4 am-utils amd/info_ldap.c amu_ldap_rebind() does:

 if (a->ldap != NULL) {
   if ((a->timestamp - now) > AMD_LDAP_TTL) {
#ifdef DEBUG
     dlog("Reestablishing ldap connection\n");
#endif /* DEBUG */
     ldap_unbind(a->ldap);
     a->timestamp = now;
   }
 }
... ldap_open()...ldap_bind_s()...

But if the cache is not expired and an ldap connection is established, I don't
think it's correct to do the ldap_open() and ldap_bind_s(). Version 6.1.5 from
upstream includes the following changes that fixes the problem:

--
       ldap_unbind(a->ldap);
       a->timestamp = now;
+      a->ldap = NULL;
+    } else {
+      /* Assume all is OK.  If it wasn't we'll be back! */
+#ifdef DEBUG
+      dlog("amu_ldap_rebind: timestamp OK\n");
+#endif /* DEBUG */
+      return (0);
     }
   }
--
returning from amu_ldap_rebind() before attempting to ldap_open() ldap_bind_s().

Version-Release number of selected component (if applicable):
am-utils-6.0.9-15

How reproducible:
Always

Steps to Reproduce:
1. setup automounter with ldap.
2. see connections leaking.
  
Actual results:
Leakage of hundreds of fd's.

Expected results:
no leakage after closing a conection.

Additional info:
[patch] attached and verified by the customer.