Karl E. Jorgensen wrote:
[snip]
I did some more narrowing down. The problem was almost certainly with
LDAP. Our LDAP server was heavily overloaded (19! Never seen a
15-minute load average that high before...) because we had an index on
the wrong key (uid instead of uidNumber, and all the queries used
uidNumber as their search term)
19 is workable. But it starts to hurt around there. I once had one of my
boxes up to 78 (didn't want to reboot as this would loose both uptime
counter and a diagnostic opportunity).
So what was apparently happening was name lookups were taking too long
(a few seconds?). Adding a proper index to slapd made the problem go
away. It's probably a bug though that ls and friends would abort if it
couldn't resolve the name in a certain amount of time though - is that
intended behavior?
I suspect that this is *not* the intended behaviour of ls :-) Sounds
like there's an obscure bug somewhere there...
Wouldn't it be better to log a timeout and use the numeric ID or
something?
I concur. But setting up a testcase for it might require a bit of
work - might not be worth it for such an obscure bug...
19 was most definitely not workable, at least by my definition. It took
me over two hours to log in :)
I can't imagine what 78 would be like... (!)
I'm also not willing to go back to reproducing the bug - this bug is on
a fairly heavily used system
and is causing a lot of mail to be incorrectly rejected. I do hope
that the bug is eventually fixed, though.
Thank you for your help, Karl :)
(To the [EMAIL PROTECTED] crowd: I've CCd this to you again. The issue seems to
be fixed, at least when I try it. Hopefully it won't rear its ugly head
again...)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
