ls在小目录中花费很长时间

运行Ubuntu，我打开一个终端并执行

sudo bash
cd /
ls | head -n 1000

并预计返回大约20个目录。

但是，如果我执行ls，并且不将其插入任何东西，ls会一直挂在那里，直到我从另一个终端杀死它为止。可能会发生什么？

编辑：

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

编辑：

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

为什么为ls的输出着色会导致此命令挂起？

— 针刺
source

运行type ls检查任何可能的别名等

— jw013

运行strace ls可以潜在地帮助您确定问题。strace显示由它调用的程序进行的所有系统调用。

— Gowtham

尝试/bin/ls（或更确切地说，command ls）在ls不使用别名选项的情况下运行，以确认是否由颜色选项产生了影响。FWIW，ls当其输出是管道或其他非终端设备时，关闭颜色。

— jw013

在命令之前运行反斜杠（而不是别名）。\ls

— 罗布

如果您正常运行ls，它将仅显示文件列表，而无需在任何文件上运行stat（2）。换句话说，它不会访问FILES本身，而只会访问包含文件的目录。

如果添加--color选项，或使用其他ls选项需要检查文件本身，则ls将需要对这些文件进行stat（2）。

实际上，目录中的至少一个文件实际上是通过NFS或类似文件从远程系统挂载的。并且您从中安装该分区的服务器没有启动或没有响应。因此，当ls尝试获取有关该目录的信息时，它将挂在内核中，等待服务器响应。

正如其他人提到的那样，如果使用strace，您将找出ls挂起时试图访问的目录。然后，您可以卸载已安装的分区或任何其他分区。

— 疯狂的科学家
source

另一种可能性是目录中的文件之一是一个符号链接，该符号链接指向某个远程分区，并且该服务器的服务器未响应...相同的原理。

— MadScientist 2012年

我从故障的服务器上挂载了nfs。似乎统计数据只是挂在nfs挂载关闭上很奇怪。不会太难分辨它是否已关闭，只需以打印出损坏的符号链接的颜色打印目录即可。

— Snitse'3

实际上，很难（对于ls而言）告诉NFS服务器已关闭。NFS只是一种不同类型的文件系统（例如ext3，xfs等）。所有文件系统都在内核中实现。诸如ls（1）之类的用户程序仅在路径名上运行诸如stat（2）之类的系统调用；它不知道正在使用哪种文件系统。在这种情况下，系统调用将挂起（因此用户空间应用程序将挂起），直到获得结果为止。因此，ls被内核休眠，直到获得结果为止……这永远不会发生。因此，我无法分辨出什么地方出了问题。

— MadScientist'1

我应该说您可以更改NFS的行为。如果您指定“硬安装”，那么如果服务器超时并且直到出现这种情况，内核都不会尝试从系统调用返回，因此内核将永远尝试重新连接。或者，您可以请求“软安装”，如果服务器请求超时，内核将以失败的方式返回。但是，许多程序/大多数程序并未编写为正确处理这些类型的超时操作，因此在NFS中指定软安装很危险，并且会导致系统不稳定。那些经常使用NFS的人几乎总是使用并建议使用硬安装。参见nfs（5）。

— MadScientist'1

我有sshfs挂载，而唯一可以挂载的方法是杀死相关文件ssh和sshfs进程。

— Gauthier