ls挂到某个目录

有一个特定的目录（/var/www），当我运行时ls（带有或不带有某些选项），该命令将挂起并且永远不会完成。中的大约只有10-15个文件和目录/var/www。通常只是文本文件。以下是一些调查信息：

[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键，然后再按Enter键，它将成功在其中按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/

由于ls挂起，我不得不多次终止终端会话：

[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。

我还应该怎么做才能调查这个问题？它只是今天随机开始发生。

更新

dmesg是一大堆东西，主要与我已挂载了太多次且已达到最大挂载数量的外部USB HDD有关，但是我认为这是不相关的问题。在底部附近，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上-这就是输出D状态的ps含义（并且由于kill无济于事，所以它是不间断的I / O系统调用之一）。大多数挂起都涉及一台NFS服务器，该服务器已经死了，但是根据您df的情况，这里不是这样。dmesg为了以防万一，快速检查与文件系统或磁盘相关的任何内容都值得。

我有同样症状的问题。原来，我在该目录中有一个通过GVFS挂接到SMB的符号链接。

lrwxrwxrwx  1 alex alex        45 Sep 16  2011 foo -> /home/alex/.gvfs/bar on foo/data/

通常ls，无论是否已安装共享，都将立即完成。但是在这种情况下，我已暂停并恢复了机器，并且安装性能总体上很差。重新安装共享可解决此问题。

我遇到了同样的问题。

输入目录很好，列出它挂起的位置，查找作品，完成制表符的挂起，并且下面的一些文件夹可以正常工作。非常头疼。

在Server Fault上读取此线程确实使我走上了通往解决方案的逻辑之路。

这与NAS有关，而NAS通常被称为“ automount”，这使我意识到，我最近已将fstab更改为“自动安装”某些USB驱动器（如果存在），但在不存在时继续正常运行。

然后，我进行如下操作：

1. 卸载包含不良目录的分区。
2. 编辑fstab并将所有自动安装转换为已注释掉或不自动。
3. 如果有，请重新加载SystemD：systemctl --system daemon-reload
4. 挂载-a

尝试再次进入目录，并获得解决该问题的那种温暖而模糊的感觉。

Womble的建议非常好，您应该先尝试一下，但是如果它们不能解决问题，那么当文件系统变得自相矛盾时（通过不稳定的硬件，晦涩的内核错误甚至是宇宙射线），我就会遇到这个问题。

如果您认为可能是这样，可以通过执行强制fsck重新启动touch /forcefsck; reboot。观察引导时的内容，以查看fsck是否发现任何不一致之处。

警告：这将使所有连接到计算机的文件系统失效。如果还连接了多PB磁盘阵列，则不要这样做，这可能需要几天的时间。 fsck文件系统也会导致数据丢失；如果您确实在文件系统中存在不一致的情况，则e2fsck会将其从看上去正确但工作不正常的文件更改为正常工作但可能未包含您期望的一切的文件。

我有与您描述的完全相同的症状。要解决此问题，我所要做的就是修复DNS服务器地址。我们已将NAS移至新网络，这需要更新DNS服务器地址。地址是静态分配的，但是在QNAP Web界面中，我将其更新为自动分配。

希望这会有所帮助，我有以上症状是由于在Ubuntu 14.04中使用AUFS驱动程序docker并docker compose与之一起引起的。ls <dir>正在挂断，并strace ls <dir>显示正在挂断getdents。停止所有正在运行的容器使我可以按预期开始使用驱动器。

运行strace ls / var / www /会给您带来错误的信息。我对/ dir有类似的问题，使用strace我可以找到它是导致它的NAS挂载。卸下该NAS可解决此问题。