特定のディレクトリで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/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システムコールの1つです）。ほとんどのハングには、神になったNFSサーバーが関係しますが、あなたに基づいて、dfここではそうではありません。念のdmesgため、ファイルシステムまたはディスクに関連するものをすばやくチェックする価値があるかもしれません。

同じ症状に問題がありました。そのディレクトリに、GVFSを介したSMBマウントへのシンボリックリンクがあることがわかりました。

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

通常ls、共有がマウントされているかどうかにかかわらず、即座に完了します。しかし、この場合、マシンをサスペンドして再開したため、マウントのパフォーマンスは全般的に低下していました。共有を再マウントすると、問題が修正されました。

同じ問題が発生していました。

ディレクトリを入力しても問題ありません。リストを表示するとハングし、作品を見つけ、タブ全体がハングし、その下のいくつかのフォルダが機能します。非常に頭がひどく奇妙です。

サーバーフォールトでこのスレッドを読んだことで、ソリューションへの論理的な道が開けました。

NASに関連しているため、NASが一般的に「自動マウント」として配置されると、USBドライブが存在する場合はfstabを「自動マウント」するように変更しましたが、存在しない場合は通常どおりに実行していることがわかりました。

その後、次のように進みました。

1. 不良ディレクトリを含むパーティションをアンマウントします。
2. fstabを編集し、すべての自動マウントをコメントアウトまたは自動なしに変換します。
3. SystemDがあれば、それをリロードします。systemctl --system daemon-reload
4. マウント-a

ディレクトリをもう一度入力してみて、問題を修正したというあたたかいあいまいさを感じてください。

Wombleの提案は優れているので、最初にそれらを試してみるべきですが、修正しない場合は、ファイルシステムが（不安定なハードウェア、あいまいなカーネルバグ、または宇宙線によって）自己矛盾になったときにこの問題が発生しました。

もしそうだと思うなら、を実行することでリブート時にfsckを強制することができますtouch /forcefsck; reboot。ブート時にfsckが矛盾を検出するかどうかを確認するために、それが何を言っているかを見てください。

警告：これにより、マシンに接続されているすべてのファイルシステムがfsckされます。マルチペタバイトのディスクアレイも接続している場合は実行しないでください。数日かかる場合があります。 fsckファイルシステムを作成すると、データが失われる可能性があります。ファイルシステムに実際に矛盾がある場合、e2fsckは、正しく見えても動作しないものから、正常に動作するが期待するすべてが含まれていないものに変更します。

あなたが説明したのとまったく同じ症状がありました。問題を解決するには、DNSサーバーのアドレスを修正するだけでした。NASを新しいネットワークに移動したため、DNSサーバーアドレスを更新する必要がありました。アドレスは静的に割り当てられていましたが、QNAP Webインターフェースでは自動で割り当てるように更新しました。

これが役に立つことを願って、私は上記の症状は、使用によって引き起こされていたdockerとdocker composeのUbuntu 14.04でAUFSドライバと。ハングしていて、通話中にハングしていることls <dir>をstrace ls <dir>示しましたgetdents。実行中のコンテナをすべて停止すると、期待どおりにドライブの使用を開始できました。

strace ls / var / www /を実行すると、何が間違っているのかがわかります。/ dirについても同様の問題があり、straceを使用して、それを引き起こしたNASマウントであることがわかりました。そのNASをアンマウントすると、問題が修正されました。