On Wed, 18 Jan 2012 17:26:01 +0000, elagrew wrote:

> "Not sure why you'd do a dsrepair when the system is dragging - dsrepair
> is a repair tool, not a diagnostic tool."
> Eh? What about ndsrepair -T or ndsrepair -E ? I use those 2 all the
> time for a quick command line diagnostic.

Years ago I switched to using iMonitor for doing diagnostics like this.
Usually a "quick command line diagnostic" leads me to need to go to
something else, and in general, it's all there in iMonitor so I just
start there now.

But yeah, that's informational and certainly OK. The thing is that
*most* people, when they say "I ran dsrepair to see what errors it
reports", they mean they've run a database repair.

First rule of troubleshooting: Don't change the environment while you're
trying to diagnose it. That changes the problem and increases the time
to troubleshoot.

Repairing the database "to see what errors are fixed" counts as changing
the environment. And in general it's not going to solve a network issue
(*rarely* it may fix a server-to-server authentication problem, but
usually comms problems are more fundamental than a corrupted key pair for
server authentication).

> At any rate, top is a good diag to use, I agree. But if you're losing
> packets, I would also check your network card and wiring.

Yes. And the switch port that the server's plugged into - I've seen bad
ports cause problems like this. And make sure that you've got the duplex
properly configured (ISTR the general rule of thumb is leave everything
set to autoconfigure, though Massimo is the expert on that around here).


Jim Henderson, CNA6, CDE, CNI, LPIC-1, CLA10, CLP10
Novell Knowledge Partner