ls taking long time in small directory

shell command-line files ls

32,573

If you run ls normally, it will just show the list of files without needing to run stat(2) on any of them. In other words, it doesn't access the FILES themselves, but only the directory that contains the files.

If you add in the --color option, or use other ls options that need to examine the files themselves, then ls will need to stat(2) those files.

Most likely at least one of the files in your directory are actually being mounted from a remote system, via NFS or similar. And the server that you've mounted that partition from is not up or not responding. So, when ls tries to get the information about that directory it will hang in the kernel waiting for the server to respond.

As others have mentioned, if you use strace you'll find out which directory ls is trying to access when it hangs. Then you can umount that mounted partition or whatever.

32,573

Snitse

Updated on September 18, 2022

Comments

Snitse over 1 year
Running Ubuntu, I open a terminal and do
```
sudo bash
cd /
ls | head -n 1000
```
And predictably about 20 directories are returned.

However, if I do an ls, and don't pipe it into anything, the ls just hangs there until I kill it from another terminal. What could be happening?

EDIT:
```
> type ls
ls is aliased to `ls --color=auto`
```
EDIT:
```
> /bin/ls /
<normal response>
> /bin/ls --color=auto
<hangs indefinitely>
```
Why is coloring the output of ls causing this command to hang?
MadScientist about 12 years

Another possibility is that one of the files in your directory is a symlink pointing to some partition that is remote and whose server is not responding... same principle.
Snitse about 12 years

I had nfs mounted from a server that was down. Seems weird that stat just hangs on the nfs mount being down. Wouldnt be too hard to tell if it was down and just print the directory in the color that broken symlinks are printed.
MadScientist about 12 years

Actually, it IS hard (for ls) to tell the NFS server is down. NFS is just a different type of filesystem (like ext3, xfs, etc.) All filesystems are implemented in the kernel. A user program like ls(1) simply runs a system call like stat(2) on a pathname; it has no idea what kind of filesystem is being used. In this case the system call hangs (so the userspace app is hung) until the result is obtained. So, ls is put to sleep by the kernel until the result is obtained... which never happens. So ls cannot tell something is wrong.
MadScientist about 12 years

I should say you CAN change the behavior of NFS. If you specify a "hard mount", then the kernel will try forever to reconnect if the server times out and won't return from the system call until that happens. Alternatively you can request a "soft mount", where the kernel returns with a failure if the server request times out. However, many/most programs are not written to properly handle these types of timeout operations, and so specifying soft mounts in NFS is dangerous and causes system instability. Those who use NFS regularly virtually always use and recommend hard mounts. See nfs(5).
Gauthier about 9 years

I had sshfs mounts, and the only way I could unmount them was by killing the related ssh and sshfs processes.