有一个特定的目录（ /var/www ），当我运行ls （有或没有一些选项）时，命令挂起并且永远不会完成。 /var/www只有大约10-15个文件和目录。 大部分只是文本文件。 这里有一些调查信息：
[me@server www]$ df . Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_dev-lv_root 50G 19G 29G 40% / [me@server www]$ df -i . Filesystem Inodes IUsed IFree IUse% Mounted on /dev/mapper/vg_dev-lv_root 3.2M 435K 2.8M 14% /
find工作正常。 另外，我可以键入cd /var/www/ ，然后在按下回车键之前按Tab键，它将成功完成列表中的所有文件/目录：
[me@server www]$ cd /var/www/ cgi-bin/ create_vhost.sh html/ manual/ phpMyAdmin/ scripts/ usage/ conf/ error/ icons/ mediawiki/ rackspace sqlbuddy/ vhosts/ [me@server www]$ cd /var/www/
我不得不几次杀掉我的terminal会话，
[me@server ~]$ ps | grep ls gdm 6215 0.0 0.0 488152 2488 ? S<sl Jan18 0:00 /usr/bin/pulseaudio --start --log-target=syslog root 23269 0.0 0.0 117724 1088 ? D 18:24 0:00 ls -Fh --color=always -l root 23477 0.0 0.0 117724 1088 ? D 18:34 0:00 ls -Fh --color=always -l root 23579 0.0 0.0 115592 820 ? D 18:36 0:00 ls -Fh --color=always root 23634 0.0 0.0 115592 816 ? D 18:38 0:00 ls -Fh --color=always root 23740 0.0 0.0 117724 1088 ? D 18:40 0:00 ls -Fh --color=always -l me 23770 0.0 0.0 103156 816 pts/6 S+ 18:41 0:00 grep ls
kill似乎没有任何影响的进程，即使sudo。
我还应该做些什么来调查这个问题？ 它只是今天随机发生的。
UPDATE
dmesg是一个很大的事情，大部分与外挂的USB硬盘相关，我已经安装了太多的时间，并且已经达到了最大安装数量，但是这是一个与我无关的问题。 在dmesg的底部附近，我看到这个：
INFO: task ls:23579 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. ls D ffff88041fc230c0 0 23579 23505 0x00000080 ffff8801688a1bb8 0000000000000086 0000000000000000 ffffffff8119d279 ffff880406d0ea20 ffff88007e2c2268 ffff880071fe80c8 00000003ae82967a ffff880407169ad8 ffff8801688a1fd8 0000000000010518 ffff880407169ad8 Call Trace: [<ffffffff8119d279>] ? __find_get_block+0xa9/0x200 [<ffffffff814c97ae>] __mutex_lock_slowpath+0x13e/0x180 [<ffffffff814c964b>] mutex_lock+0x2b/0x50 [<ffffffff8117a4d3>] do_lookup+0xd3/0x220 [<ffffffff8117b145>] __link_path_walk+0x6f5/0x1040 [<ffffffff8117a47d>] ? do_lookup+0x7d/0x220 [<ffffffff8117bd1a>] path_walk+0x6a/0xe0 [<ffffffff8117beeb>] do_path_lookup+0x5b/0xa0 [<ffffffff8117cb57>] user_path_at+0x57/0xa0 [<ffffffff81178986>] ? generic_readlink+0x76/0xc0 [<ffffffff8117cb62>] ? user_path_at+0x62/0xa0 [<ffffffff81171d3c>] vfs_fstatat+0x3c/0x80 [<ffffffff81258ae5>] ? _atomic_dec_and_lock+0x55/0x80 [<ffffffff81171eab>] vfs_stat+0x1b/0x20 [<ffffffff81171ed4>] sys_newstat+0x24/0x50 [<ffffffff810d40a2>] ? audit_syscall_entry+0x272/0x2a0 [<ffffffff81013172>] system_call_fastpath+0x16/0x1b
而且， strace ls /var/www/吐出了一大堆信息。 我不知道这里有什么用处……最后一行：
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, TIOCGWINSZ, {ws_row=68, ws_col=145, ws_xpixel=0, ws_ypixel=0}) = 0 stat("/var/www/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/var/www/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 fcntl(3, F_GETFD) = 0x1 (flags FD_CLOEXEC) getdents(3, /* 16 entries */, 32768) = 488 getdents(3, /* 0 entries */, 32768) = 0 close(3) = 0 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 9), ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3093b18000 write(1, "cgi-bin conf create_vhost.sh\te"..., 125cgi-bin conf create_vhost.sh error html icons manual mediawiki phpMyAdmin rackspace scripts sqlbuddy usage vhosts ) = 125 close(1) = 0 munmap(0x7f3093b18000, 4096) = 0 close(2) = 0 exit_group(0) = ?
运行strace ls /var/www/并查看它挂起的内容。 它当然挂在I / O上 – 这就是ps输出中的D状态（因为kill不起作用，它是不可中断的I / O系统调用之一）。 大多数挂起涉及到一个NFS服务器，上帝，但基于你的df ，这不是这里的情况。 以防万一，快速检查dmesg与文件系统或磁盘有关的任何事情可能是值得的。
我有一个相同的症状问题。 事实certificate，我在该目录中的一个符号链接到GVFS上的SMB挂载。
lrwxrwxrwx 1 alex alex 45 Sep 16 2011 foo -> /home/alex/.gvfs/bar on foo/data/
通常ls会立即完成是否共享被安装。 但是在这种情况下，我已经暂停和恢复了机器，一般来说，坐骑performance不佳。 重新安装共享解决了这个问题。
我遇到了同样的问题。
进入一个目录是好的，列出它挂起，find作品，标签完成挂起，并在一些文件夹下工作。 非常奇怪。
在“服务器故障”中读取这个线程的确让我走向了解决scheme的逻辑path。
这与NAS有关，NAS通常被认为是“自动挂载（automount）”，这让我意识到，如果我们最近已经改变了自己的“自动挂载”方式，但是在没有存在的情况下继续正常运行。
我接着进行如下：
尝试再次进入目录，并得到解决问题的温暖模糊的感觉。
Womble的build议是非常好的，你应该先尝试一下，但是如果它们没有解决的话，当文件系统变得不一致时（通过碎片硬件，模糊的内核错误，甚至是宇宙射线），我都会遇到这个问题。
如果你认为可能是这样的话，你可以通过touch /forcefsck; reboot强制重启fsck touch /forcefsck; reboot touch /forcefsck; reboot 。 看看它在启动时说什么，看看fsck是否有任何不一致之处。
警告 ：这将fsck连接到机器的所有文件系统; 不要这样做，如果你还有一个多PB的磁盘arrays，可能需要几天时间 。 丢失文件系统也会导致数据丢失; 如果您的文件系统中确实存在不一致的情况，e2fsck会将其从一个看起来正确但不起作用的更改为正常工作，但可能不包含您期望的所有内容。
在希望这会有所帮助，我有上面的症状是由于在Ubuntu 14.04中使用docker和docker compose与AUFS驱动程序docker compose 。 ls <dir>挂着， strace ls <dir>显示挂在getdents呼叫上。 停止所有正在运行的容器允许我按照预期开始使用驱动器。
运行strace ls / var / www /会给你后面的错误。 我有类似的问题的/目录和使用strace我能够find它是一个NAS安装它造成的。 卸下NAS解决问题。