26

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?

Improve this question
4
  • 3
    Run type ls to check any possible aliases etc. Commented Mar 29, 2012 at 16:28
  • 6
    Running strace ls can potentially help you identify the issue. strace displays all system calls made by the program it invokes. Commented Mar 29, 2012 at 16:29
  • 2
    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. Commented Mar 29, 2012 at 17:31
  • 3
    a backslash before a command runs it instead of the alias, as well. \ls Commented Mar 29, 2012 at 18:20

1 Answer 1

Reset to default
35

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.

Improve this answer
5
  • 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. Commented Mar 29, 2012 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. Commented Mar 29, 2012 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. Commented Apr 1, 2012 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). Commented Apr 1, 2012 at 17:03
  • I had sshfs mounts, and the only way I could unmount them was by killing the related ssh and sshfs processes. Commented Apr 1, 2015 at 15:37

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.