Есть конкретный каталог (/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
завершится мгновенно, независимо от того, смонтирован общий ресурс. Но в этом случае я приостановил и возобновил работу машины, и в целом установка работала плохо. Повторная установка доли устранила проблему.
В надежде, что это будет полезно, у меня были вышеупомянутые симптомы, вызванные использованием docker
и docker compose
с драйвером AUFS в Ubuntu 14.04. ls <dir>
висел, и strace ls <dir>
показал, что он висит на getdents
вызов. Остановка всех запущенных контейнеров позволила мне начать использовать диск должным образом.
У меня была такая же проблема.
Вход в каталог - это нормально, список зависаний, поиск работ, полное зависание вкладки и некоторые папки внизу делать работай. Очень странно-головокружительно.
Чтение этой ветки на Server Fault действительно привело меня к логическому пути к решению.
Это связано с NAS, а NAS, обычно обозначаемый как «automount», заставил меня понять, что я недавно изменил свой fstab на «automount» некоторых USB-накопителей, если они присутствовали, но продолжал работать как обычно, когда их не было.
Затем я поступил следующим образом:
Попробуйте войти в каталог еще раз, и у вас возникнет теплое нечеткое ощущение, что проблема устранена.
Предложения Уомбла превосходны, и вы должны сначала попробовать их, но если они не исправят это, у меня была эта проблема, когда файловая система стала самосогласованной (из-за нестабильного оборудования, непонятных ошибок ядра или даже космических лучей).
Если вы думаете, что это может быть так, вы можете принудительно запустить fsck при перезагрузке, выполнив touch /forcefsck; reboot
. Посмотрите, что он говорит во время загрузки, чтобы увидеть, обнаружит ли fsck какие-либо несоответствия.
Предупреждение: это проверит все файловые системы, подключенные к машине; не делайте этого, если к вам подключен многопетабайтный дисковый массив, это может занять дней. fsck
Использование файловых систем также может привести к потере данных; если у вас действительно есть несоответствия в вашей файловой системе, e2fsck изменит ее с той, которая выглядит правильно, но не совсем работает, на ту, которая работает правильно, но может содержать не все, что вы ожидаете.
У меня были те же самые симптомы, что вы описали. Чтобы решить эту проблему, мне нужно было исправить адреса DNS-серверов. Мы переместили NAS в новую сеть, что потребовало обновления адресов DNS-серверов. Адреса были назначены статически, но в веб-интерфейсе QNAP я обновил их, чтобы они назначались автоматически.
Запуск strace ls / var / www / даст вам понять, что не так. У меня была аналогичная проблема для / dir, и с помощью strace я смог определить, что это было причиной крепления NAS. Отключение этого NAS устранило проблему.