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/и нажать TAB перед нажатием Enter, и он успешно завершит список завершения всех файлов / каталогов там:

[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, который я монтировал слишком много раз, и был достигнут максимальный счетчик монтирования, но я думаю, что это не связанная проблема. В нижней части 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/и посмотри на чем он висит. Он определенно зависает от ввода / вывода - это то, что означает Dсостояние в вашем psвыводе (и, поскольку killэто не помогает, это одна из системных вызовов непрерывного ввода / вывода). Большинство зависаний связано с NFS-сервером, который ушел от Бога, но на основании вашего, dfчто здесь не так. На dmesgвсякий случай может быть полезна быстрая проверка всего, что связано с файловыми системами или дисками.

У меня была проблема с такими же симптомами. Оказалось, что в этом каталоге у меня была символическая ссылка на монтирование SMB через GVFS.

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

Обычно lsзавершается мгновенно независимо от того, был ли установлен общий ресурс. Но в этом случае я приостановил и возобновил работу машины, а крепление в целом работало плохо. Перемонтирование ресурса решило проблему.

Я испытывал ту же проблему.

Ввод каталога в порядке, в котором перечислены он висит, найти работы, вкладка полные зависания и некоторые папки под сделать работу. Очень головокружительно странно.

Чтение этой темы о сбое сервера привело меня к логическому пути к решению.

Это связано с NAS, и NAS, обычно обозначаемый как «automount», заставил меня осознать, что я недавно изменил свой fstab на «autount» некоторых usb-накопителей, если они присутствовали, но продолжали работать как обычно, когда их не было.

Затем я поступил следующим образом:

1. Размонтируйте раздел, содержащий каталог delinquent.
2. Отредактируйте fstab и конвертируйте все автомонтирование в закомментированные или без авто.
3. Перезагрузите SystemD, если он у вас есть: systemctl --system daemon-reload
4. гора -а

Попробуйте снова войти в каталог и почувствуйте это нечеткое ощущение, что проблема исправлена.

Предложения Womble превосходны, и вы должны попробовать их в первую очередь, но если они не исправят это, у меня возникла эта проблема, когда файловая система стала самосогласованной (из-за нестабильного оборудования, неясных ошибок ядра или даже космических лучей).

Если вы думаете, что это так, вы можете принудительно перезагрузить fsck touch /forcefsck; reboot. Посмотрите, что он говорит во время загрузки, чтобы увидеть, обнаруживает ли fsck какие-либо несоответствия.

Предупреждение : это будет fsck всех файловых систем, подключенных к машине; не делайте этого, если у вас также есть подключенный дисковый массив с несколькими петабайтами, это может занять несколько дней . fsckфайловые системы также могут привести к потере данных; если у вас действительно есть несоответствия в вашей файловой системе, e2fsck изменит ее с той, которая выглядит правильно, но не совсем работает, на ту, которая работает правильно, но может содержать не все, что вы ожидаете.

У меня были те же самые симптомы, которые вы описали. Чтобы решить проблему, все, что мне нужно было сделать, это исправить адреса DNS-сервера. Мы переместили NAS в новую сеть, что потребовало обновления адресов DNS-серверов. Адреса были назначены статически, но в веб-интерфейсе QNAP я обновил его для автоматического назначения.

В надежде, что это будет полезно, у меня были вышеуказанные симптомы, вызванные использованием dockerи docker composeс драйвером AUFS в Ubuntu 14.04. ls <dir>висел, и strace ls <dir>показал, что он висит на getdentsвызове. Остановка всех запущенных контейнеров позволила мне начать использовать диск, как и ожидалось.

Запуск strace ls / var / www / покажет вам, что не так. У меня была похожая проблема для / dir, и, используя strace, я смог обнаружить, что это было связано с подключением NAS. Размонтирование этого NAS решило проблему.