I should have subscribed to this list years ago...

I have a problem with an LDAP search.  In one particular script, it's returning 
a non-zero result code, with an error message of "I/O interrupted system call." 
 In addition, the "net-ldap-socket" field in the LDAP object is disappearing 
(verified through a Dumper output of the LDAP object.)  This occurs whether the 
LDAP object is scoped to the innermost loop, or globally scoped (reusing the 
connection.)

Here's a chunk of code:

                                until (defined($LDAP->{'net_ldap_socket'})) {
                                                $LDAP_REGEN++;
                                                if 
(!defined($LDAP->{'net_ldap_socket'})) {
                                                                $LDAP = 
Net::LDAP->new("ldap://localhost";);
                                                }
                                                $result = $LDAP->search (
                                                                "base" => 
$CFG{"base_dn"},
                                                                "scope" => 
"sub",
                                                                "filter" => 
$ldapsearch,
                                                                "attrs" => 
['uid', 'uidnumber', 'gidnumber', 'gecos', 'homedirectory', 'loginshell' ]
                                                                );
                                }

The problem crops up during the $LDAP->search call.  I've discovered that if I 
check the resultCode field, or the existence of the net-ldap-socket field, for 
the error condition, and simply loop until successful, I will get the intended 
results.  At the moment, out of some 85-90 expected searches, it's having to 
regen the LDAP object some 60-65 times.   This condition is somewhat consistent 
in that the failed searches do occasionally change, but only slightly from 
execution to execution.  It also doesn't seem to matter if I connect to 
ldap://localhost, ldaps://localhost, ldap://some.other.host, 
ldaps://some.other.host, etc.  Even when changing from non-secure to secure 
connections, the error appears to be largely similar.

Running a wireshark capture against this traffic shows a connection 
reset(closure) from the script side, not the server side.

Environment:
<jkalc>:(/home/jkalc/389-ds)
$ cat /etc/redhat-release
CentOS release 6.6 (Final)
<jkalc>:(/home/jkalc/389-ds)
$ rpm -qa | grep -i ^perl
perl-Array-Utils-0.5-1.el6.noarch
perl-Excel-Writer-XLSX-0.84-1.el6.noarch
perl-Pod-Escapes-1.04-136.el6_6.1.x86_64
perl-Module-Load-0.16-136.el6_6.1.x86_64
perl-IPC-Cmd-0.56-136.el6_6.1.x86_64
perl-Archive-Extract-0.38-136.el6_6.1.x86_64
perl-Digest-SHA-5.47-136.el6_6.1.x86_64
perl-Parse-CPAN-Meta-1.40-136.el6_6.1.x86_64
perl-Net-SSLeay-1.35-9.el6.x86_64
perl-NetAddr-IP-4.027-7.el6.x86_64
perl-MIME-Lite-3.027-2.el6.noarch
perl-5.10.1-136.el6_6.1.x86_64
perl-ExtUtils-MakeMaker-6.55-136.el6_6.1.x86_64
perl-IO-Zlib-1.09-136.el6_6.1.x86_64
perl-Compress-Raw-Bzip2-2.021-136.el6_6.1.x86_64
perl-Test-Simple-0.92-136.el6_6.1.x86_64
perl-DBD-SQLite-1.27-3.el6.x86_64
perl-HTML-Parser-3.64-2.el6.x86_64
perl-Digest-SHA1-2.12-2.el6.x86_64
perl-Text-Iconv-1.7-6.el6.x86_64
perl-TermReadKey-2.30-13.el6.x86_64
perl-TimeDate-1.16-13.el6.noarch
perl-Pod-Simple-3.13-136.el6_6.1.x86_64
perl-XML-Dumper-0.81-8.el6.noarch
perl-Locale-Maketext-Simple-0.18-136.el6_6.1.x86_64
perl-Log-Message-0.02-136.el6_6.1.x86_64
perl-devel-5.10.1-136.el6_6.1.x86_64
perl-Compress-Raw-Zlib-2.021-136.el6_6.1.x86_64
perl-Archive-Tar-1.58-136.el6_6.1.x86_64
perl-Log-Message-Simple-0.04-136.el6_6.1.x86_64
perl-Module-CoreList-2.18-136.el6_6.1.x86_64
perl-IO-Compress-Bzip2-2.021-136.el6_6.1.x86_64
perl-parent-0.221-136.el6_6.1.x86_64
perl-Time-Piece-1.15-136.el6_6.1.x86_64
perl-HTML-Tagset-3.20-4.el6.noarch
perl-XML-SAX-0.96-7.el6.noarch
perl-libxml-perl-0.08-10.el6.noarch
perl-Digest-HMAC-1.01-22.el6.noarch
perl-XML-SAX-Writer-0.50-8.el6.noarch
perl-Socket6-0.23-4.el6.x86_64
perl-Proc-ProcessTable-0.48-1.el6.x86_64
perl-Archive-Zip-1.30-2.el6.noarch
perl-MailTools-2.04-4.el6.noarch
perl-DBI-1.609-4.el6.x86_64
perl-libs-5.10.1-136.el6_6.1.x86_64
perl-XML-Twig-3.34-1.el6.noarch
perl-Params-Check-0.26-136.el6_6.1.x86_64
perl-IO-Compress-Base-2.021-136.el6_6.1.x86_64
perl-ExtUtils-ParseXS-2.2003.0-136.el6_6.1.x86_64
perl-IO-Compress-Zlib-2.021-136.el6_6.1.x86_64
perl-File-Fetch-0.26-136.el6_6.1.x86_64
perl-Term-UI-0.20-136.el6_6.1.x86_64
perl-Module-Loaded-0.02-136.el6_6.1.x86_64
perl-Module-Build-0.3500-136.el6_6.1.x86_64
perl-CGI-3.51-136.el6_6.1.x86_64
perl-Time-HiRes-1.9721-136.el6_6.1.x86_64
perl-XML-LibXML-1.70-5.el6.x86_64
perl-XML-Parser-2.36-7.el6.x86_64
perl-Convert-ASN1-0.22-1.el6.noarch
perl-Net-LibIDN-0.12-3.el6.x86_64
perl-LDAP-0.40-1.el6.noarch
perl-Config-General-2.52-1.el6.noarch
perl-Mozilla-LDAP-1.5.3-4.el6.x86_64
perl-Crypt-SSLeay-0.57-17.el6.x86_64
perl-Authen-SASL-2.13-3.el6.noarch
perl-Email-Date-Format-1.002-5.el6.noarch
perl-XML-Grove-0.46alpha-40.el6.noarch
perl-version-0.77-136.el6_6.1.x86_64
perl-Test-Harness-3.17-136.el6_6.1.x86_64
perl-Compress-Zlib-2.021-136.el6_6.1.x86_64
perl-Object-Accessor-0.34-136.el6_6.1.x86_64
perl-ExtUtils-Embed-1.28-136.el6_6.1.x86_64
perl-core-5.10.1-136.el6_6.1.x86_64
perl-DBIx-Simple-1.32-3.el6.noarch
perl-libwww-perl-5.833-2.el6.noarch
perl-XML-Filter-BufferText-1.01-8.el6.noarch
perl-IO-Socket-SSL-1.31-2.el6.noarch
perl-Net-DNS-0.65-5.el6.x86_64
perl-MIME-Types-1.28-2.el6.noarch
perl-URI-1.40-2.el6.noarch
perl-Module-Pluggable-3.90-136.el6_6.1.x86_64
perl-Module-Load-Conditional-0.30-136.el6_6.1.x86_64
perl-Package-Constants-0.02-136.el6_6.1.x86_64
perl-ExtUtils-CBuilder-0.27-136.el6_6.1.x86_64
perl-CPAN-1.9402-136.el6_6.1.x86_64
perl-CPANPLUS-0.88-136.el6_6.1.x86_64
perl-XML-NamespaceSupport-1.10-3.el6.noarch
perl-GSSAPI-0.26-6.el6.x86_64

I don't recall seeing this sort of error on other search calls, I'll have to 
spin through some other scripts I have here to verify.  I do rather strongly 
suspect that I've got something strange happening in this script, as I've been 
able to abstract out the searches, and use them in another script en masse 
successfully and on the first pass through.

Any suggestions on what/where to look next?

Jeff Kalchik
Systems Engineering
Land O'Lakes
This message may contain confidential material from Land O'Lakes, Inc. (or its 
subsidiary) for the sole use of the intended recipient(s) and may not be 
reviewed, disclosed, copied, distributed or used by anyone other than the 
intended recipient(s). If you are not the intended recipient, please contact 
the sender by reply email and delete all copies of this message.

Reply via email to