'ls' hangs FC6

Todd Denniston Todd.Denniston at ssa.crane.navy.mil
Thu Apr 10 19:53:43 UTC 2008


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 at ercbroadband.org> 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




More information about the fedora-list mailing list