Bug 468049 - Directory listing hangs if NFS mountpoint is not available
Directory listing hangs if NFS mountpoint is not available
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: coreutils (Show other bugs)
9
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Ondrej Vasik
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-22 11:11 EDT by Andrew Cannon
Modified: 2008-10-24 06:13 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-24 06:13:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andrew Cannon 2008-10-22 11:11:40 EDT
Description of problem:
When using any RH based Linux system (the problem has appeared in RH3 and 4 and now Fedora 9) with NFS mounts (mounted via the use of a SunOS NIS master server), any directory listing of the root directory, where the soft links to the /newhome directory are, produces a very long delay (of the order of 5 minutes at least) if the mount points are not found.  This is not usually a problem because we can remove the offending links if they are not needed (usually because a machine has 'died').  However, we have just installed a laptop and the laptop needs to have soft links in the root directory to NFS mounts on the rest of the network.  This causes a hang when doing an ls on the root directory.


Version-Release number of selected component (if applicable): 
Fedora 9:  kernel2.6.26.3-29.fc9.x86_64
coreutils: 6.10
NFS v 4
autofs-5.0.3-15.x86_64


How reproducible: Always


Steps to Reproduce:
1. ln -s /newhome/users /users
2. Ensure /users is not listed in NIS maps or otherwise unavailable to client
3. ls / 
  
Actual results:
This results in a hang of the terminal while autofs tries to mount the non-existent directory.

Expected results:
The system should fail gracefully, say within a few seconds after not being able to find the directory over NFS.

Additional info:
Comment 1 Kamil Dudka 2008-10-22 12:22:12 EDT
Did you try ls --color=never? If the problem is gone, it is caused by checking symlink validity for color highlighting. You can add something like this to your profile:
eval `dircolors -b | sed s/or=[^:]*:/or=:/`
Comment 2 Andrew Cannon 2008-10-23 04:19:20 EDT
Kamil, thanks, the colors=never option worked.  The next question is, why does it take so long to highlight items in colour?  Surely it shouldn't take long to do this?

Anyway, thanks for your help.  Does this class as a bug or just another PEBKAC?

Andy
Comment 3 Kamil Dudka 2008-10-24 06:13:58 EDT
I can't see any bug within ls or coreutils since this is about NFS behavior. If you don't care if symlinks are valid, use proposed solution to disable symlink checking.

If you have any idea how to solve this (patch for ls or somewhat), feel free to reopen.

Note You need to log in before you can comment on or make changes to this bug.