解決策 1:
strace ls /var/www/ を実行 そして、それが何にかかっているかを見てください。それは確かに I/O でハングアップしています -- それが D ps の状態 出力手段 (および kill 以降) 役に立ちません。これは、中断できない I/O システムコールの 1 つです)。ほとんどのハングは、神に行った NFS サーバーに関係していますが、あなたの df に基づいています ここではそうではありません。 dmesg の簡単なチェック 念のため、ファイルシステムやディスクに関連するものは価値があるかもしれません.
解決策 2:
同じ症状で困っていました。そのディレクトリに、GVFS を介した SMB マウントへのシンボリック リンクがあることがわかりました。
lrwxrwxrwx 1 alex alex 45 Sep 16 2011 foo -> /home/alex/.gvfs/bar on foo/data/
通常 ls 共有がマウントされているかどうかに関係なく、即座に完了します。しかし、この場合、マシンを一時停止して再開したため、マウントは一般的にパフォーマンスが低下していました。共有を再マウントすると問題が解決しました。
解決策 3:
これが役立つことを願って、 docker を使用して上記の症状が発生しました と docker compose Ubuntu 14.04 の AUFS ドライバーで。 ls <dir> ぶら下がっていて、strace ls <dir> getdents にぶら下がっていることを示しました 電話。実行中のすべてのコンテナーを停止すると、期待どおりにドライブを使用できるようになりました。
解決策 4:
同じ問題が発生しました。
ディレクトリに入ると問題なく、リストがハングし、作品が見つかり、タブが完全にハングし、do の下のいくつかのフォルダがハングします 仕事。非常に頭が痛くなるほど奇妙です。
Server Fault に関するこのスレッドを読んだことで、ソリューションへの論理的な道筋をたどることができました。
これは NAS に関係しており、一般的に「自動マウント」と呼ばれる NAS は、最近 fstab を変更して、USB ドライブが存在する場合は「自動マウント」し、存在しない場合は通常どおり続行するように変更したことに気付きました。
その後、次のように進めました:
<オール>もう一度ディレクトリに入ってみて、問題が解決したというほのぼのした気持ちになってください。