Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?


> type ls
ls is aliased to `ls --color=auto`


> /bin/ls /
<normal response>
> /bin/ls --color=auto
<hangs indefinitely>

Why is coloring the output of ls causing this command to hang?

share|improve this question
Run type ls to check any possible aliases etc. –  jw013 Mar 29 '12 at 16:28
Running strace ls can potentially help you identify the issue. strace displays all system calls made by the program it invokes. –  Gowtham Mar 29 '12 at 16:29
Try /bin/ls (or rather, command ls) to run ls without the aliased options, to confirm whether or not it is the color option that is making a difference. FWIW, ls turns off coloring when its output is a pipe or other non-terminal device. –  jw013 Mar 29 '12 at 17:31
a backslash before a command runs it instead of the alias, as well. \ls –  Rob Mar 29 '12 at 18:20
add comment

1 Answer

up vote 17 down vote accepted

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.

share|improve this answer
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. –  MadScientist Mar 29 '12 at 18:42
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. –  Snitse Mar 29 '12 at 19:20
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 Apr 1 '12 at 16:58
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). –  MadScientist Apr 1 '12 at 17:03
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.