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것입니다. 대부분의 중단은 신에게 갔다 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는 일반적으로 '자동 마운트'로 배치되어 최근에 일부 USB 드라이브가있는 경우 fstab을 '자동 마운트'하도록 변경했지만 그렇지 않은 경우 정상적으로 유지한다는 것을 깨달았습니다.

그런 다음 다음과 같이 진행했습니다.

1. 불량 디렉토리가 포함 된 파티션을 마운트 해제하십시오.
2. fstab을 편집하고 모든 자동 마운트를 주석 처리되었거나 자동으로 변환하십시오.
3. SystemD가있는 경우 SystemD를 다시로드하십시오. systemctl --system daemon-reload
4. 마운트 -a

디렉토리를 다시 입력하고 문제를 해결 한 따뜻한 느낌을 받으십시오.

Womble의 제안은 훌륭하고 먼저 시도해야하지만 문제를 해결하지 않으면 파일 시스템이 자체 불일치 할 때 (플래시 하드웨어, 모호한 커널 버그 또는 우주 광선을 통해)이 문제가 발생했습니다.

그럴 수도 있다고 생각되면 재부팅하여 fsck를 강제로 재부팅 할 수 있습니다 touch /forcefsck; reboot. 부팅시 fsck가 불일치를 선택하는지 확인하십시오.

경고 : 시스템에 연결된 모든 파일 시스템을 fsck합니다. 멀티 페타 바이트 디스크 어레이도 연결되어 있으면 며칠 이 걸릴 수 있습니다 . fsck파일 시스템을 사용하면 데이터가 손실 될 수도 있습니다. 파일 시스템에 불일치가있는 경우 e2fsck는 파일을 올바르게 보이지만 작동하지 않는 것으로 변경하지만 제대로 작동하지만 예상 한 모든 것을 포함하지 않을 수있는 파일 시스템으로 변경합니다.

당신이 묘사 한 것과 똑같은 증상이 나타났습니다. 문제를 해결하려면 DNS 서버 주소를 수정해야합니다. NAS를 새로운 네트워크로 옮기고 DNS 서버 주소를 업데이트해야했습니다. 주소는 정적으로 할당되었지만 QNAP 웹 인터페이스에서 자동으로 할당되도록 업데이트했습니다.

이것이 도움이되기를 희망 하면서, Ubuntu 14.04의 AUFS 드라이버를 사용 docker하고 사용하여 위의 증상이 발생했습니다 docker compose. ls <dir>걸려서 전화를 strace ls <dir>걸고 있음을 보여주었습니다 getdents. 실행중인 모든 컨테이너를 중지하면 예상대로 드라이브 사용을 시작할 수있었습니다.

strace ls / var / www /를 실행하면 무엇이 잘못되었는지 뒷받침합니다. / dir과 비슷한 문제가 있었고 strace를 사용하면 NAS 마운트가 원인이었습니다. NAS를 마운트 해제하면 문제가 해결되었습니다.