[Date Prev][Date Next]
Re: (ITS#3855) recovery from EBADF error for slapd
On Jul 11, 2005, at 2:31 PM, Howard Chu wrote:
> ITS#3400 was supposed to correct the counter, so that the limit of
> 16 tries gets detected and then slapd shuts down. Do you have a
> test case to reproduce the EBADF situation in the first place, that
> demonstrates that the patch for ITS#3400 is still broken? (Note
> that the fix of ITS#3400 is part of 2.2.19.)
It looks like this fix was done in before I merged in 2.2.19 actually
(I know, bad Jason for only just submitting this patch now), so at
the time I was running into the 100% CPU rather than an abnormal exit
of slapd which is what ITS 3400 provided. Either way I think having
slapd be able to recover from this on its own is better.
> The patch looks interesting; probably it should break out of the
> loop after it detects a single bad descriptor. (It is already
> pretty rare to have one bad descriptor, what's the likelihood of
> more than one?)
That would be easy enough to do. If there was more than one bad
descriptor though you'd have to iterate over the descriptors once for
each of them in that case.
> I haven't looked closely at the code yet, does it work with
> outbound connections too (e.g. syncrepl consumer)?
We don't currently use syncrepl so it's possible this patch needs to
be modified to take that into account... are those connections in the
same connection pool as incoming connections?