我使用 Linux Mint 13，有时（很少）我发现自己无法列出我的主目录内容。当我尝试这样做时：
$ cd
$ ls
然后，ls就只能无限期地等待。当任何其他应用程序尝试读取目录内容时，情况都是如此：我最终必须杀死该应用程序。
我已经使用这个 Linux 发行版大约一年了，我的机器通常总是开启（24/7），几周前我第一次遇到这个问题。然后，我只是尝试关闭所有应用程序，但这没有帮助，然后我重新启动机器，它有所帮助：问题已“修复”。
今天我又遇到了。这次我试图找到更多关于原因的信息：我用谷歌搜索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
答案1
如果文件系统驱动程序从不响应，则尝试访问文件系统的进程将无限期地阻塞。
对于存储在存储设备上的文件系统来说，不响应的主要原因是底层硬件没有响应或者出现故障。这通常会在内核日志中产生大量消息（在dmesgLinux 上或在相应的日志文件中可见/var/log/kern.log），并最终导致超时和 I/O 错误 (EIO)。
支持网络的文件系统可能不会响应，因为没有来自服务器的响应，这可能是因为网络已关闭、服务器计算机已关闭、或者服务器程序未运行或配置不正确。根据文件系统类型、驱动程序及其配置，这可能会导致超时或无限等待。特别是 NFS，默认为无限等待：它是无状态的（如果服务器在操作过程中出现故障，操作可以在服务器返回时恢复），因此客户端会阻塞，直到服务器响应（因为如果服务器响应）最终返回，文件系统将正常运行）。
对于 FUSE 文件系统，这取决于实现该文件系统的程序。 FUSE 非常灵活，可以由任意程序实现。硬币的反面是，有时 FUSE 文件系统内部不是很健壮，或者依赖于许多可能出现故障的其他组件。
如果文件系统没有响应，请首先检查它是什么类型的文件系统。在 Linux 上，在/proc/mounts;中查找挂载点挂载点是第二个字段，文件系统类型是第三个字段。这会告诉您在哪里寻找更多线索：
- 对于存储设备上的文件系统，请查看内核日志。
- 对于网络支持的文件系统，请检查网络连接并检查服务器是否正在响应。相关日志通常位于服务日志中（例如
/var/log/syslog或/var/log/daemon.log或特定于网络服务的日志）。 - 对于 FUSE 文件系统，检查进程是否正在响应。
如果您的进程在 I/O 中被阻塞，并且您已经放弃等待文件系统恢复，您可能需要强制卸载文件系统。如果它是 FUSE 文件系统，杀死提供它的进程就可以了。对于任何类型的文件系统，在 Linux 上，您可以使用以下命令执行“延迟卸载” umount -l：这会将文件系统与其安装点分离，即使文件系统驱动程序被卡住；驱动程序继续运行（例如，如果它正在做的话，它会继续与硬件通信）。