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 схоже, це не впливає на процеси, навіть як судо.

Що ще я повинен зробити для розслідування цієї проблеми? Це просто випадково почалося сьогодні.

ОНОВЛЕННЯ

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 на "automount" деякі usb-накопичувачі, якщо вони були, але вони працювали як звичайно, коли їх не було.

Потім я поступив так:

1. Демонтуйте розділ, що містить каталог делінквентів.
2. Відредагуйте fstab та перетворіть усі автоматичні автомати на коментовані або без автоматичних.
3. Перезавантажте SystemD, якщо у вас є: systemctl - система daemon-reload
4. гора -а

Спробуйте зайти знову в каталог і отримайте тепле нечітке відчуття, що вирішили проблему.

Пропозиції Womble відмінні, і ви повинні спробувати їх спершу, але якщо вони не виправлять це, у мене виникла ця проблема, коли файлова система стала непослідовною (через невміле обладнання, незрозумілі помилки ядра чи навіть космічні промені).

Якщо ви думаєте, що це може бути так, ви можете змусити fsck при перезавантаженні, виконавши touch /forcefsck; reboot. Подивіться, що він пише під час завантаження, щоб побачити, чи не виявляє fsck непослідовність.

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

У мене були такі самі точні симптоми, що ви описали. Щоб виправити проблему, я повинен був виправити адреси DNS-сервера. Ми перенесли NAS в нову мережу, яка потребувала оновлення адрес DNS-сервера. Адреси були призначені статично, але у веб-інтерфейсі QNAP я оновив його для автоматичного призначення.

Сподіваючись, що це буде корисним, у мене були зазначені вище симптоми, викликані використанням dockerта docker composeдрайвером AUFS в Ubuntu 14.04. ls <dir>повісив і strace ls <dir>показав, що він висить на getdentsдзвінку. Зупинення всіх запущених контейнерів дозволило мені почати використовувати привід, як очікувалося.

Виконання страз ls / var / www / дасть вам зрозуміти, що не так. У мене була аналогічна проблема для / dir, і за допомогою strace я зміг знайти, що це кріплення NAS, яке викликало це. Не враховуючи, що NAS усунула проблему.