Bug 468049

Summary:	Directory listing hangs if NFS mountpoint is not available
Product:	[Fedora] Fedora	Reporter:	Andrew Cannon <andrew.cannon>
Component:	coreutils	Assignee:	Ondrej Vasik <ovasik>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	9	CC:	kdudka, ovasik, twaugh
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-10-24 10:13:58 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Andrew Cannon 2008-10-22 15:11:40 UTC

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 16:22:12 UTC

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 08:19:20 UTC

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 10:13:58 UTC

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.