Here's a demonstration of the problem. First a successful reuse: May 17 17:57:40 goose spampd[29529]: debug: ldapBlacklist: input data found ... proceeding with searches May 17 17:57:40 goose spampd[29529]: debug: ldapBlacklist: searching for (objectclass=*) May 17 17:57:41 goose spampd[29529]: debug: ldapBlacklist: LDAP probe succeeded for ldap://localhost:389/ou=Mail-Filters,ou=Services,dc=ehsco,dc=com/
The next message that came into the same process crapped out: May 17 17:58:14 goose spampd[29529]: debug: ldapBlacklist: input data found ... proceeding with searches May 17 17:58:14 goose spampd[29529]: debug: ldapBlacklist: searching for (objectclass=*) May 17 18:02:59 goose spampd[29529]: Failed to run LDAP_RDNS_FROM_WHITE SpamAssassin test, skipping: (Timed out! ) Note the ~4 minute delay between query and timeout. The next message milked by that process also worked fine, and the existing ldap session was reused just fine: May 17 18:09:05 goose spampd[29529]: debug: ldapBlacklist: input data found ... proceeding with searches May 17 18:09:05 goose spampd[29529]: debug: ldapBlacklist: searching for (objectclass=*) May 17 18:09:06 goose spampd[29529]: debug: ldapBlacklist: LDAP probe succeeded for ldap://localhost:389/ou=Mail-Filters,ou=Services,dc=ehsco,dc=com/ Looking at the ldap logfile however shows that the "failing" query was actually processed successfully: May 17 17:58:14 goose slapd[16685]: conn=3857 op=468 SRCH base="ou=Mail-Filters,ou=Services,dc=ehsco,dc=com" scope=0 filter="(objectClass=*)" May 17 17:58:14 goose slapd[16685]: conn=3857 op=468 SRCH attr=objectClass May 17 17:58:14 goose slapd[16685]: conn=3857 op=468 SEARCH RESULT tag=101 err=0 nentries=1 text= For some reason, Net::LDAP either didn't get the answer, didn't pass the answer back to my script, or didn't return an error that I could trap. Even more confusing, this only happens when I make the session persistent, and it never happens when I create/destroy per-message sessions (but that doesn't seem to matter, since as demonstrated subsequent messages seem to still get processed just fine). If anybody has any ideas here I'd appreciate hearing them. Thanks Original message below for context: Eric A. Hall wrote: > What's the recommended method for testing to see if a search has > produced any results? > > I've got a strange problem and I'm pretty certain that there's some > kind of synchronization issue between my search and reads. > > In more detail and for background information, I'm working on an > LDAP-based blacklist plugin for SpamAssassin. By default, the plugin > runs in a non-persistent mode, such that new LDAP sessions are > established for each incoming message, queries are run, and the session > is destroyed. This all seems to work pretty well, but its a lot of > sessions to deal with. > > For efficiency I am trying to get the processes to run in persistent > mode, so that a daemonized instance of SA can reuse a single LDAP > session for the lifetime of that process (each instance of SA gets its > own session). This seems to work for a little while, but eventually it > develops a timeout condition where the LDAP search results don't get > caught, so the plugin hangs which causes a cascade of timeout-related > problems. My current (development) code has: > > # # issue the LDAP search # $permsgstatus->{ldap_search_result} = > $self->{ldap_session}->search( base => $self->{ldap_search_base}, > filter => $permsgstatus->{ldap_search_filter}, scope => > $self->{ldap_search_scope}, deref => $self->{ldap_search_deref}, > timelimit => $self->{ldap_timeout}, attrs => > [$permsgstatus->{ldap_resource_attr}]); > > # # see if there was a problem # if ((! defined > $permsgstatus->{ldap_search_result}) || > ($permsgstatus->{ldap_search_result}->error ne "Success")) { > > # # report the error if it's defined # if (defined > $permsgstatus->{ldap_search_result}) { > > dbg ("ldapBlacklist\: search failed with \"" . > $permsgstatus->{ldap_search_result}->error . "\""); } > > # # disconnect the session politely # dbg ("ldapBlacklist\: unable to > proceed " . "... terminating"); > > $self->destroy_ldap_session($permsgstatus); > > # # kill the module so that nothing more happens # die; } > > I'm not getting any hits on this when persistency is enabled and when a > failure occurs. I checked the LDAP logs and the queries are definitely > getting processed, so my guess here is that I'm running into some kind > of synchronization problem and I need to wait for the query to be > answered or errored as appropriate. > > Any suggestions here? > > Thanks
