![ls 在 strace 下的行为有所不同](https://linux22.com/image/22564/ls%20%E5%9C%A8%20strace%20%E4%B8%8B%E7%9A%84%E8%A1%8C%E4%B8%BA%E6%9C%89%E6%89%80%E4%B8%8D%E5%90%8C.png)
我不知道如何调试这种情况:
1)我尝试执行:
ls /home/user
2) ls 阻塞并且不打印任何内容。我认为这是因为 /home/user 包含 /home/user/sshfs_files,这是一个 sshfs 挂载的目录,但我的机器上的网络出现故障(网络再次启动,但我猜 SSH 连接已丢失)。
3)因为我想确定 sshfs 挂载的目录是导致挂起的原因,所以我在 strace 下尝试了相同的命令:
strace -o /tmp/log ls /home/user
4) ls 确实起作用了!所以现在的情况是 ls 在 strace 下工作但自己阻塞。
这怎么可能呢?这种情况该如何解释呢?如果 ls 在 strace 下不阻塞,我怎样才能看到它在哪里阻塞?
谢谢!
答案1
作为jw13指出,这几乎是“ls 在小目录中花费很长时间“ - 至少就解释而言。请务必阅读那里的评论!
简而言之,ls
当某些流行的命令行程序的输出不直接发送到终端时,它们的操作方式会有所不同。在这种情况下ls
, 可能是 的别名ls --color=auto
,它尝试检测每个目录条目的类型以进行着色。此时它挂起,无法stat
对您的 sshfs 安装目录执行操作。
添加到MadScientist 对上述问题的回答:如果您好奇如何strace
或gdb
可以帮助调试ls
'行为,我建议您运行类似的东西
strace -o /tmp/log ls --color=always /home/user
答案2
嗯,这是调试中的程序的常见行为,并且实际上无法避免。变量的初始化发生变化,有更多可用信息,程序流程发生变化。
要么获取 ls 的源代码,然后通过不同的调试器运行它,希望它会显示错误,要么尝试通过其他方式找到答案、解决方法。