[Pkg-openldap-devel] Bug#495316: ldap-utils: ldapsearch hangs quering a busy/dead/hanged server (-l x ineffective))

[Paolo]

I'd have an argument to rise the P to 'important', as it breaks things
badly: ldapsearch is run in a script run by cron via run-parts; since it
hangs it prevents the whole maintenance set to go on and complete.

So tried and dig further myself to find the culprit; seems that 'timeout'
option is seldom (never?) used directly, instead functions check for

  ld->ld_options.ldo_tm_api

whereas -l x sets 

  ld->ld_options.ldo_timelimit

hacking libraries/libldap/options.c so that @~700 it looks like:
...        
        case LDAP_OPT_TIMELIMIT:
                /* FIXME: check value for protocol compliance? */
                lo->ldo_timelimit = * (const int *) invalue;
                if (lo->ldo_tm_api.tv_sec <= 0) {           
                        const struct timeval *tv =
                                { (const int *) invalue };
                        lo->ldo_tm_api = *tv;
                }
                return LDAP_OPT_SUCCESS;
        
        case LDAP_OPT_TIMEOUT: {
                        const struct timeval *tv =
                                (const struct timeval *) invalue;

                        lo->ldo_tm_api = *tv;
                } return LDAP_OPT_SUCCESS;

...

solves my problem:

# ldapsearch ... -l3 -d3
...
ldap_result ld 0x8088c68 msgid 1
wait4msg ld 0x8088c68 msgid 1 (timeout 2999999 usec)
...
ldap_chkResponseList returns ld 0x8088c68 NULL
ldap_int_select
ldap_parse_result
ldapsearch: error.c:272: ldap_parse_result: Assertion `r != ((void *)0)' failed.
Aborted

after ~3s.
It's clearly a *kludge*, in the *wrong place* (library) but the statically
compiled binary WFM, till a true fix comes along (into Etch as well, 
possibly).


HTH
thx
-- 
paolo