web-dev-qa-db-ja.com

小さなディレクトリで長い時間がかかる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の出力を色分けすると、このコマンドがハングするのはなぜですか？

shellcommand-linefilesls
23
Snitse

Lsを通常どおり実行すると、stat（2）を実行する必要なく、ファイルのリストが表示されます。つまり、ファイル自体にはアクセスせず、ファイルを含むディレクトリにのみアクセスします。

--colorオプションを追加するか、ファイル自体を調べる必要がある他のlsオプションを使用する場合、lsはそれらのファイルをstat（2）する必要があります。

ほとんどの場合、ディレクトリ内の少なくとも1つのファイルが、NFSなどを介してリモートシステムから実際にマウントされています。そして、そのパーティションをマウントしたサーバーが起動していないか、応答していません。そのため、lsがそのディレクトリに関する情報を取得しようとすると、サーバーが応答するのを待ってカーネルでハングします。

他の人が述べたように、straceを使用すると、ハングしたときにlsがアクセスしようとしているディレクトリがわかります。次に、マウントされたパーティションなどをマウント解除できます。

31
MadScientist