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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
