ls treo cho một thư mục nhất định

Có một thư mục cụ thể ( /var/www), khi tôi chạy ls(có hoặc không có một số tùy chọn), lệnh sẽ bị treo và không bao giờ hoàn thành. Chỉ có khoảng 10-15 tập tin và thư mục trong /var/www. Chủ yếu chỉ là tập tin văn bản. Dưới đây là một số thông tin điều tra:

[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% /

findhoạt động tốt Ngoài ra tôi có thể nhập cd /var/www/và nhấn TAB trước khi nhấn enter và nó sẽ thành công danh sách hoàn thành tab của tất cả các tệp / thư mục trong đó:

[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/

Tôi đã phải giết các phiên cuối của mình nhiều lần vì lsbị treo:

[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 dường như không có bất kỳ ảnh hưởng nào đến các quy trình, ngay cả khi sudo.

Tôi nên làm gì khác để điều tra vấn đề này? Nó chỉ ngẫu nhiên bắt đầu xảy ra ngày hôm nay.

CẬP NHẬT

dmesglà một danh sách lớn các thứ, chủ yếu liên quan đến ổ cứng USB ngoài mà tôi đã gắn quá nhiều lần và đã đạt được số lượng gắn kết tối đa, nhưng đó là một vấn đề không liên quan tôi nghĩ. Gần cuối dmesgtôi đang thấy điều này:

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

Và cũng, strace ls /var/www/phun ra một BUNCH thông tin. Tôi không biết những gì hữu ích ở đây ... Một số dòng cuối cùng:

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)                           = ?

Chạy strace ls /var/www/và xem những gì nó treo trên. Nó chắc chắn được treo trên I / O - đó là ý nghĩa của Dtrạng thái trong psđầu ra của bạn (và vì killnó không giúp ích gì, nó là một trong những tòa nhà I / O không bị gián đoạn). Hầu hết các lần treo máy đều liên quan đến một máy chủ NFS đã bị dftrục trặc, nhưng dựa trên đó không phải là trường hợp của bạn ở đây. Việc kiểm tra nhanh dmesgmọi thứ liên quan đến hệ thống tập tin hoặc đĩa có thể đáng giá, chỉ trong trường hợp.

Tôi đã có một vấn đề với các triệu chứng tương tự. Hóa ra tôi đã có một liên kết tượng trưng trong thư mục đó để gắn kết SMB qua GVFS.

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

Thông thường lssẽ hoàn thành ngay lập tức cho dù chia sẻ được gắn kết hay không. Nhưng trong trường hợp này, tôi đã treo và nối lại máy, và nói chung là hoạt động kém. Kể lại việc chia sẻ đã khắc phục vấn đề.

Tôi đã trải qua vấn đề tương tự.

Nhập một thư mục là tốt, liệt kê nó bị treo, tìm công việc, treo hoàn thành tab và một số thư mục bên dưới làm việc. Rất đầu-lạ-lạ.

Đọc chủ đề này trên Server Fault đã đưa tôi đến một con đường logic hướng tới giải pháp.

Nó liên quan đến NAS và NAS thường được đặt là 'automount' khiến tôi nhận ra rằng gần đây tôi đã thay đổi fstab của mình thành 'automount' một số ổ USB nếu chúng có mặt nhưng vẫn hoạt động như bình thường khi chúng không hoạt động.

Sau đó tôi đã tiến hành như sau:

1. Ngắt kết nối phân vùng chứa thư mục phạm pháp.
2. Chỉnh sửa fstab và chuyển đổi tất cả tự động sang nhận xét hoặc không có tự động.
3. Tải lại SystemD nếu bạn có nó: systemctl --system daemon-reload
4. gắn kết -a

Hãy thử vào thư mục một lần nữa và có được cảm giác mờ nhạt ấm áp của việc khắc phục vấn đề.

Các đề xuất của Womble là tuyệt vời và bạn nên thử chúng trước, nhưng nếu chúng không khắc phục được thì tôi đã gặp vấn đề này khi hệ thống tập tin trở nên không nhất quán (thông qua phần cứng dễ vỡ, lỗi hạt nhân che khuất hoặc thậm chí là tia vũ trụ).

Nếu bạn nghĩ rằng nó có thể là như vậy, bạn có thể buộc một fsck khởi động lại bằng cách thực hiện touch /forcefsck; reboot. Xem những gì nó nói khi khởi động, để xem fsck có nhận được bất kỳ mâu thuẫn nào không.

Cảnh báo : điều này sẽ fsck tất cả các hệ thống tập tin được gắn vào máy; không làm điều đó nếu bạn cũng có một mảng đĩa nhiều petabyte, có thể mất vài ngày . fsckhệ thống tập tin ing cũng có thể dẫn đến mất dữ liệu; nếu bạn thực sự có sự không nhất quán trong hệ thống tệp của mình, e2fsck sẽ thay đổi nó từ một cái có vẻ đúng nhưng không hoạt động, thành một thứ hoạt động đúng nhưng có thể không chứa mọi thứ bạn mong đợi.

Tôi đã có các triệu chứng chính xác giống như bạn mô tả. Để khắc phục sự cố, tất cả những gì tôi phải làm là sửa các địa chỉ máy chủ DNS. Chúng tôi đã chuyển NAS sang một mạng mới, yêu cầu cập nhật địa chỉ máy chủ DNS. Các địa chỉ được gán tĩnh, nhưng trong giao diện web QNAP tôi đã cập nhật nó để tự động gán.

Với hy vọng điều này sẽ hữu ích, tôi đã có các triệu chứng trên do sử dụng dockervà docker composevới trình điều khiển AUFS trong Ubuntu 14.04. ls <dir>đã treo, và strace ls <dir>cho thấy nó được treo trên getdentscuộc gọi. Dừng tất cả các container đang chạy cho phép tôi bắt đầu sử dụng ổ đĩa như mong đợi.

Chạy strace ls / var / www / sẽ cung cấp cho bạn những gì sai. Tôi gặp vấn đề tương tự đối với / dir và sử dụng strace tôi có thể xác định vị trí của nó là một gắn kết NAS gây ra nó. Unmounting rằng NAS đã khắc phục vấn đề.