Added an alarm around the search call (using Sys::SigAction) and the problem persisted.
Did some further debugging and the hang actually occurs around ldap_error_text call after checking $mesg-code. Surprisingly this call was actually within the bounds of the alarm (I only set alarm(0) after). Has anyone seen this before? Any idea why it would handle an alarm sisgnal? Could the hang be delayed somehow from the search call? Thanks again for any help, Chris --- Chris Masters <[EMAIL PROTECTED]> wrote: > Thanks for that information Chris. > > Problem is that I have the same problem with my > mysql > dbi connection and I'm not sure if I can get the > socket connect handle there. I'll dig further. > > --- Chris Ridd <[EMAIL PROTECTED]> wrote: > > On 17/3/05 11:13 pm, Chris Masters > > <[EMAIL PROTECTED]> wrote: > > > > > Thanks Chris, that looks much simpler than an > > external > > > timeout mechanism. > > > > Only if it fools your firewall ;-) > > > > > The default timeout for SO_KEEPALIVE seems to be > 2 > > > hours. Any ideas how I can change this to 30 > mins > > for > > > example? > > > > This is a parameter of your machine's TCP stack. > On > > darwin and FreeBSD you'd > > do 'sysctl -w net.inet.tcp.keepintvl=nnn', on > Linux > > you'd 'echo nnn > > > /proc/sys/net/ipv4/tcp_keepalive_intvl' (2.4 and > > later kernels) and on > > Windows you'll probably have to change something > > well documented in the > > registry! > > > > Cheers, > > > > Chris > > > > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam > protection around > http://mail.yahoo.com > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
