[Date Prev][Date Next] [Chronological] [Thread] [Top]

openldap 1.1 to 1.1.4 killing network



Ok, I have been having a serious problem with semi lock-ups on my sparc
Linux box over the past few months. It would show itself after a few
days to a week by seemingly locking out network connections. The weird
thing was that connections to services were accepted and ESTABLISHED
according to netstat, and connecting to non-listening ports met with a
connection refused. Problem was that none of the services were spawned
to connect with the incoming connection, and showed no logs of such.

Since the machine is remote to me, my assumption was a user space
lockup with the kernel still active (strange since watchdog didn't even
reboot it). After getting my service provider to reboot, everything
seemed fine again. Until this last Friday, when the machine would not
come back up properly, but stayed in this "half awake" state after
every reboot.

So I went to investigate directly, to rid myself of the problem
completely. What I found was that killing slapd cleared the symptoms
with out a trace. I tried starting it back up and trying different
combinations of enabled services, and everytime slapd was the culprit.
During this frozen state, all inbound network connection were locked,
but non-network binaries (such as ls, cd, swapon, mount) worked with
out problems. My guess is a serious breakdown in the user level
networking layer caused by slapd, or simply triggered by slapd.

Here is some relevant versions for the time period I have been affected
by this:

glibc 2.0.101 to 2.0.105
linux kernel 2.1.130 to 2.2.1 (with sparc patches from davem)
SPARC LX (sun4m)

Sorry I can't do further testing on this until I find a way to make my
machine kill slapd when the symptoms show (an hour drive to the service
providor with a $2 toll isn't worth it :).

Hope this helps in solving this bug.

--
-----    -- - -------- --------- ----  -------  -----  - - ---   --------
Ben Collins <b.m.collins@larc.nasa.gov>                  Debian GNU/Linux
UnixGroup Admin - Jordan Systems Inc.                 bcollins@debian.org
------ -- ----- - - -------   ------- -- The Choice of the GNU Generation