Mark Haney wrote, On 04/10/2008 02:37 PM:
Todd Denniston wrote:
Mark Haney wrote, On 04/10/2008 02:06 PM:
Rick Stevens wrote:
Paul Johnson wrote:
On Wed, Apr 9, 2008 at 1:26 PM, Mark Haney
<mhaney@xxxxxxxxxxxxxxxx> wrote:
Does anyone have any ideas on why 'ls' would suddenly stop
working? I've got
a FC6 box that acts as a SAN host and for the last week or so I
can't ls
anything. It sits and does nothing. Everything else on the box
works just
fine except for that.
I've got no idea how to even go about debugging this.
I have seen this on systems that are using LDAP for authentication.
They don't just authenticate at start time, but they look up user
information every time. Every single time any command is run, the
system goes off to check user identity on a server. When there is
network slowdown or server slowdown, then ls is slow. For us, the
short term fix was to install the nscd to cache the information so the
system does not constantly look on the server. The long term fix was
to stop authenticating users with LDAP.
Or run "ls -ln" so you don't do user/group lookups and simply display
the numbers.
It must be something with the user/group lookups then because an
ls-ln works just fine. I just can't figure out /why/ it's a problem now.
does the ls which hangs, output SOME of the info before it hangs?
perhaps something like the following could be useful...
for i in *
do
OPTIONS_THAT_HANG_LS="--color=tty"
/bin/ls $OPTIONS_THAT_HANG_LS $i && \
echo "$i" >> /tmp/files_that_did_not_hang_ls.txt &
done
of course you'll have a bunch of ls's hanging when this is done.
`killall -9 ls` them?
/bin/ls > /tmp/wholedir.txt
diff -u /tmp/files_that_did_not_hang_ls.txt \
/tmp/wholedir.txt | \
grep -e "+" >/tmp/trouble
then for the files in /tmp/trouble (after looking to see if someone on
this list does not pull a flamethrower on Todd for the suggestion)
for i in $TROUBLEMAKERS
do
#just ignore the problem
#chown root:root $i
#If that don't fix it, I am at a loss,
#or you are loosing hardware.
#
#try to figure out if it is a consistent user
# or group causing the problem.
#ls -ln $i
done
Strangely the system hangs before displaying ANY files. If it did a
few, it might be something I could nail down myself.
Now, I'm getting more and more sure that it's a user/group resolution
problem since the ls -ln option works in every case where both ls and ls
-l hang.
I was not clear (did not state) but the above scripts should (I think) operate
as expected even if you are seeing it hang before displaying ANY files, and
pretty much depend on it. :) Sorry for the confusion.
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
