99423 - When the LDAP service is not avail the system locks up.

Status: VERIFIED DUPLICATE of bug 79509

(MailNews Core :: LDAP Integration, defect)

Description

[Jason Boerner]

0) Turn off the LDAP service on your remote host
1) Configure Netscape to use the remote service 
   a) Edit/Pref
   b) +Mail/News
   c) Addressing
   d) X Directory Server
2) Open News/Mail
3) Compose New
4) In the To: field start typeing a name
The system will hang so badly that the only way out is to open up a console from
a remote location and do a killall mozilla-bin.

Is there a non-blocking call that can be used here or can we verify that the
service is at least available before running out to it?
I also have an strace if you really want more details.

The end of my strace looks like this:
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 35
connect(35, {sin_family=AF_INET, sin_port=htons(389),
sin_addr=inet_addr("192.168.0.1")}}, 16) = ? ERESTARTSYS (To be restarted)
--- SIGTERM (Terminated) ---
+++ killed by SIGTERM +++

Comment 1

[Srilatha Moturi]

comments from dmose on irc

<dmose>	just turning off the ldap service on the remote host should immediately 
cause a TCP connection-refused to be sent back
<dmose>	so that shouldn't happen
<dmose>	conceivably my connect fix could fix that problem
<dmose>	but maybe not

The connect bug # is 79509.
Reassinging this bug to dmose

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

If you feel like trying the connect patch in 79509 (though it's not completely
finished yet), it would be interesting to know if that fixes your problem.

Comment 3

[Jason Boerner]

Note that in my test case step .5 is:

.5) start Mozilla

I can also repro. on earlier versions.
Currently I'm using:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010816

Tested Under Linux 2.4.7 & 2.4.9

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

Jason: that's the circumstance I was referring to: when Mozilla first tries to
connect, it should immediately be sent a TCP CONNECTION_REFUSED packet by the
kernel of the other machine.

Comment 5

[Jason Boerner]

I have finally figured it out and the problem is that the firewall is simply not
allowing the packets through.  I think that it is important to note that many
distributions now ship this way.

It seems to me that the behavior a user would expect is for the timeout to
happen quickly giving the user a chance to turn off LDAP for this session. It is
so important that the system not appear as though it has locked up.  

Could we not at least test for the service first by using a non-blocking call so
that user can get more feedback from the event?

<Snippet from log>
Sep 17 20:07:40 server kernel: Packet log: eth0i DENY eth0 PROTO=6
192.168.0.252:34420 192.168.0.1:389 L=60 S=0x00 I=14369 F=0x4000 T=64 SYN (#55)
Sep 17 20:07:43 server kernel: Packet log: eth0i DENY eth0 PROTO=6
192.168.0.252:34420 192.168.0.1:389 L=60 S=0x00 I=14370 F=0x4000 T=64 SYN (#55)

Comment 6

[Dan Mosedale (:dmosedale, :dmose)]

This is definitely a duplicate of 79509; that fix should make this problem go away.

*** This bug has been marked as a duplicate of 79509 ***

Comment 7

[yulian chang]

Verified duo.