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:
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=:/`
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
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.