Не удалось отобразить содержимое каталога: процесс бесконечно бесконечно

Я использую Linux Mint 13, а иногда (редко) я не могу перечислить содержимое моего домашнего каталога. Когда я пытаюсь это сделать:

$ cd $ ls 

то, ls просто ждет бесконечно. То же самое с любым другим приложением, когда он пытается прочитать содержимое каталога: я должен в конечном итоге убить это приложение.

  • перечислить все файлы, более новые, чем заданные временные метки, и отсортировать их
  • Как определить, сколько файлов находится в каталоге без учета?
  • Когда был открыт последний файл?
  • du и ls сообщают о неправильном размере каталога
  • Как рассчитывается размер каталога?
  • Как я могу перечислять скрытые каталоги, затем каталоги, затем скрытые файлы и, наконец, файлы с ls?
  • Я использовал этот дистрибутив Linux примерно на год, моя машина обычно всегда (24/7), и я впервые столкнулся с этой проблемой пару недель назад. Затем я просто попытался закрыть все приложения, которые не помогли, затем я перезагрузил машину, и это помогло: проблема была «исправлена».

    Сегодня я снова столкнулся с этим. На этот раз я попытался найти немного больше о причине: я googled lsof , попытался использовать его, но … он ждет бесконечно! Более того, он ждет, даже если я попытаюсь lsof любой каталог, а не только домашний каталог. Скажем, $ lsof /path/to/any/file заставляет lsof ждать бесконечно.

    На всякий случай, я попытался использовать lsof на удаленной машине через ssh, он работает. Таким образом, это похоже на более глубокую проблему на моей локальной машине.

    Если кто-нибудь знает, как понять, где проблема, ваша помощь высоко ценится.

    (Я не собираюсь перезагружать машину сейчас, я надеюсь поймать причину)

    UPD: части выхода dmesg :

     Nov 12 14:35:36 dimon-progr kernel: [1305000.288107] INFO: task lsof:32463 blocked for more than 120 seconds. Nov 12 14:35:36 dimon-progr kernel: [1305000.288112] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Nov 12 14:35:36 dimon-progr kernel: [1305000.288116] lsof D c1044aa0 0 32463 1 0x00000084 Nov 12 14:35:36 dimon-progr kernel: [1305000.288122] f10f3dc0 00000086 f10f3d68 c1044aa0 00000001 f3108ca0 c18e43c0 c18e43c0 Nov 12 14:35:36 dimon-progr kernel: [1305000.288132] eea0a18a 0004a2af f45073c0 ee00a5e0 ed9c25e0 ee00a5e0 f10f3db4 f10f3d84 Nov 12 14:35:36 dimon-progr kernel: [1305000.288141] c105be37 ee00a5e0 f10f3d9c c105c535 00000296 f10f3d9c f10f3d9c c1027378 Nov 12 14:35:36 dimon-progr kernel: [1305000.288150] Call Trace: Nov 12 14:35:36 dimon-progr kernel: [1305000.288160] [<c1044aa0>] ? try_to_wake_up+0x140/0x190 Nov 12 14:35:36 dimon-progr kernel: [1305000.288167] [<c105be37>] ? recalc_sigpending+0x17/0x40 Nov 12 14:35:36 dimon-progr kernel: [1305000.288172] [<c105c535>] ? __set_task_blocked+0x35/0x80 Nov 12 14:35:36 dimon-progr kernel: [1305000.288178] [<c1027378>] ? default_spin_lock_flags+0x8/0x10 Nov 12 14:35:36 dimon-progr kernel: [1305000.288183] [<c1576d2d>] ? _raw_spin_lock_irqsave+0x2d/0x40 Nov 12 14:35:36 dimon-progr kernel: [1305000.288188] [<c1575135>] schedule+0x35/0x50 Nov 12 14:35:36 dimon-progr kernel: [1305000.288193] [<c121755d>] request_wait_answer+0x6d/0x1f0 Nov 12 14:35:36 dimon-progr kernel: [1305000.288198] [<c106a390>] ? add_wait_queue+0x50/0x50 Nov 12 14:35:36 dimon-progr kernel: [1305000.288203] [<c1217758>] fuse_request_send+0x78/0xb0 Nov 12 14:35:36 dimon-progr kernel: [1305000.288208] [<c121bd6c>] fuse_do_getattr+0x12c/0x280 Nov 12 14:35:36 dimon-progr kernel: [1305000.288213] [<c113d80d>] ? complete_walk+0x7d/0x100 Nov 12 14:35:36 dimon-progr kernel: [1305000.288219] [<c121c381>] fuse_update_attributes+0x41/0xa0 Nov 12 14:35:36 dimon-progr kernel: [1305000.288224] [<c121c684>] fuse_getattr+0x44/0x50 Nov 12 14:35:36 dimon-progr kernel: [1305000.288228] [<c11370e2>] vfs_getattr+0x42/0x70 Nov 12 14:35:36 dimon-progr kernel: [1305000.288233] [<c121c640>] ? fuse_listxattr+0x130/0x130 Nov 12 14:35:36 dimon-progr kernel: [1305000.288237] [<c113716c>] vfs_fstatat+0x5c/0x80 Nov 12 14:35:36 dimon-progr kernel: [1305000.288241] [<c11371e0>] vfs_stat+0x20/0x30 Nov 12 14:35:36 dimon-progr kernel: [1305000.288245] [<c1137456>] sys_stat64+0x16/0x30 Nov 12 14:35:36 dimon-progr kernel: [1305000.288251] [<c100ceec>] ? syscall_trace_enter+0x15c/0x170 Nov 12 14:35:36 dimon-progr kernel: [1305000.288256] [<c1576ed4>] syscall_call+0x7/0xb Nov 12 14:35:36 dimon-progr kernel: [1305000.288260] [<c1570000>] ? encode+0x26/0x2b 

  • Как сократить текущий путь к каталогу, указанный на терминале?
  • Проверка в ksh, если каталог пуст
  • Все, что есть _not_ символическая ссылка
  • Сортировка списка файлов
  • Разный цвет для диапазона KiB в `ls -l`
  • Вопрос о разрешениях иерархических каталогов
  • One Solution collect form web for “Не удалось отобразить содержимое каталога: процесс бесконечно бесконечно”

    Процессы, пытающиеся получить доступ к блоку файловой системы бесконечно, если драйвер файловой системы никогда не отвечает.

    Для файловой системы, которая хранится на запоминающем устройстве, основной причиной не реагирования является то, что основное оборудование не отвечает или не работает. Обычно это приводит к появлению больших сообщений в журналах ядра (видимых с помощью dmesg в Linux или в соответствующем файле журнала, таких как /var/log/kern.log ) и в конечном итоге вызывает тайм-аут и ошибку ввода-вывода (EIO).

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

    Для файловых систем FUSE это зависит от программы, реализующей файловую систему. FUSE очень гибкий, поскольку он может быть реализован произвольными программами. Обратная сторона монеты заключается в том, что иногда файловые системы FUSE не очень надежны внутри или зависят от множества других компонентов, которые могут ошибочно работать.

    Если файловая система не отвечает, сначала проверьте, какой тип файловой системы она есть. В Linux найдите точку монтирования в /proc/mounts ; точка монтирования является вторым полем, а тип файловой системы – третьим. Это говорит вам, где искать дополнительные подсказки:

    • Для файловых систем на запоминающем устройстве просмотрите журналы ядра.
    • Для файловых систем с сетевой поддержкой проверьте сетевое подключение и проверьте, отвечает ли сервер. Релевантные журналы обычно находятся в журналах служб (например, /var/log/syslog или /var/log/daemon.log или журнал, специфичный для сетевой службы).
    • Для файловых систем FUSE проверьте, отвечает ли процесс.

    Если у вас есть процессы, заблокированные в I / O, и вы отказались от ожидания восстановления файловой системы, вы можете принудительно отключить файловую систему. Если это файловая система FUSE, то убийство процесса, обеспечивающего ее, сделает трюк. Для любого типа файловой системы в Linux вы можете выполнить «ленивый размонтинг» с помощью umount -l : это отделяет файловую систему от точки монтирования, даже если драйвер файловой системы застрял; драйвер продолжает работать (например, он продолжает связываться с оборудованием, если это то, что он делает).

    Linux и Unix - лучшая ОС в мире.