Re: [exim] Exim hangs on ldap search

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Lou Vasquez
Dátum:  
Címzett: Alain Williams
CC: exim-users
Tárgy: Re: [exim] Exim hangs on ldap search
I don't know why I didn't think to try that. Must be the years of
having to compile debug into code and run in a debugger.

I tried it just now but it doesn't look like its in a loop. It just
hangs. See below. It's clearly getting the right answer (the cn), but
it's almost like it's expecting more but never gets it. Like I said
though the same search with ldapsearch from the cmd line works great.

Just in case in all my other changes something in the config has changed
I'm attaching that too.

Thanks,
Lou

***config
    server_condition = \
                ${lookup ldap\


{user="cn=<snip>,cn=Users,dc=ercbroadband,dc=local" \
                        pass=<snip> \


ldaps://chapman.ercbroadband.org/cn=Users,dc=ercbroadband,dc=local?cn?sub?(sAMAccountName=$1)}\
                {works}fail}}



**output
[pid 31572] write(2, "14:46:16 31572 Start search\n", 2814:46:16 31572 
Start search
) = 28
[pid 31572] time(NULL)                  = 1153680376
[pid 31572] gettimeofday({1153680376, 893124}, NULL) = 0
[pid 31572] getrusage(RUSAGE_SELF, {ru_utime={0, 60000}, ru_stime={0, 
20000}, ...}) = 0
[pid 31572] time(NULL)                  = 1153680376
[pid 31572] times({tms_utime=6, tms_stime=2, tms_cutime=0, 
tms_cstime=0}) = 524330776
[pid 31572] gettimeofday({1153680376, 893288}, NULL) = 0
[pid 31572] getrusage(RUSAGE_SELF, {ru_utime={0, 60000}, ru_stime={0, 
20000}, ...}) = 0
[pid 31572] time(NULL)                  = 1153680376
[pid 31572] times({tms_utime=6, tms_stime=2, tms_cutime=0, 
tms_cstime=0}) = 524330784
[pid 31572] write(10, 
"\27\3\1\0k\331\274\237\247G\237\10-`\314\367P\\\316\354"..., 112) = 112
[pid 31572] select(1024, [10], [], NULL, NULL) = 1 (in [10])
[pid 31572] read(10, "\27\3\1\0\212", 5) = 5
[pid 31572] read(10, 
"E\230\333\214%\320\1\326\354\f\267\224\34\301\0\315\266"..., 138) = 138
[pid 31572] gettimeofday({1153680376, 982524}, NULL) = 0
[pid 31572] getrusage(RUSAGE_SELF, {ru_utime={0, 60000}, ru_stime={0, 
20000}, ...}) = 0
[pid 31572] time(NULL)                  = 1153680376
[pid 31572] times({tms_utime=6, tms_stime=2, tms_cutime=0, 
tms_cstime=0}) = 524330785
[pid 31572] gettimeofday({1153680376, 982698}, NULL) = 0
[pid 31572] getrusage(RUSAGE_SELF, {ru_utime={0, 60000}, ru_stime={0, 
20000}, ...}) = 0
[pid 31572] time(NULL)                  = 1153680376
[pid 31572] times({tms_utime=6, tms_stime=2, tms_cutime=0, 
tms_cstime=0}) = 524330785
[pid 31572] time(NULL)                  = 1153680376
[pid 31572] getpid()                    = 31572
[pid 31572] write(2, "14:46:16 31572 ldap_result loop\n", 3214:46:16 
31572 ldap_result loop
) = 32
[pid 31572] time(NULL)                  = 1153680376
[pid 31572] getpid()                    = 31572
[pid 31572] write(2, "14:46:16 31572 LDAP entry loop\n", 3114:46:16 
31572 LDAP entry loop
) = 31
[pid 31572] time(NULL)                  = 1153680376
[pid 31572] getpid()                    = 31572
[pid 31572] write(2, "14:46:16 31572 LDAP attr loop cn"..., 4514:46:16 
31572 LDAP attr loop cn:Lou Vasquez
) = 45
[pid 31572] time(NULL)                  = 1153680376
[pid 31572] select(1024, [10], [], NULL, NULL
Alain Williams wrote:

> On Sat, Jul 22, 2006 at 02:44:23PM -0400, Lou Vasquez wrote:
>
>> I noticed that but assumed that since I don't have any outgoing firewall
>> restrictions (I'll double check that) that this wasn't the problem. I
>> tried snooping the packets to see if it was doing this but forgot that I
>> was using ldaps and couldn't see didly.
>>
>
> When I was debugging my problem I used strace and found that it was in a loop
> attempting to connect to the same 6 ldap servers, over & again.
>
> What does strace tell you it is doing. If something is 'hung' it is usually either
> in a loop or it is stuck waiting for some system call to end.
>
>
>> I'll try implementing the patch and compiling from scratch this week if
>> I can get to it. First I'm going to try debugging from AD as well as my
>> perl hack, but I'd rather have a good patch in the long run :)
>>
>
>