strace是Linux下直接追踪程序系统调用的调试工具，通过拦截并记录进程与内核的交互，帮助排查权限错误、程序卡死、性能瓶颈、崩溃等问题；常用选项包括-f（追踪子进程）、-e（过滤系统调用）、-o（输出到文件）、-T（显示耗时）等，可结合grep、awk等工具分析输出；其局限在于性能开销大、仅限系统调用层面、输出冗杂，适用于初步排查，深度分析需结合ltrace、perf或eBPF等工具。
在Linux系统里，想要窥探一个程序到底在“幕后”做了些什么，比如它打开了哪些文件、访问了哪些网络地址、分配了多少内存，甚至为什么会崩溃，
strace
就是我们最直接、最趁手的工具。它能追踪并记录一个进程或命令所执行的所有系统调用，这些系统调用是用户空间程序与内核交互的唯一途径。简而言之，
strace
就是把程序和操作系统之间的“对话”原原本本地记录下来，让我们一览无余。
解决方案
strace
的使用其实非常直观，它的核心功能就是拦截并打印出程序执行的系统调用及其参数、返回值。
最基础的用法，就是直接在命令前加上
strace
：
strace ls -l
这会显示
ls -l
命令在执行过程中所有的系统调用。你会看到大量的
openat
、
read
、
stat
等调用，以及它们对应的文件路径、权限参数和返回值。
如果一个程序已经在运行，你想追踪它，可以使用
-p
选项，后面跟上进程ID（PID）：
strace -p
比如，你发现一个服务进程行为异常，或者卡住了，就可以用这种方式去看看它当前正在做什么。这在排查死锁或长时间等待资源的问题时特别有用。
一些常用的
strace
选项：
-o
：将
strace
的输出重定向到一个文件，而不是标准错误输出。这对于长时间运行的程序或输出量巨大的情况非常关键。
-e
：过滤系统调用。这是
strace
最强大的功能之一。你可以指定只追踪某些类型的系统调用，比如只看文件相关的
open,read,write
，或者只看网络相关的
socket,connect,sendto,recvfrom
。
-f
：追踪子进程。如果被追踪的程序会fork出新的子进程，加上这个选项可以确保所有子进程的系统调用也被追踪到。
-T
：显示每个系统调用花费的时间。这对于发现性能瓶颈很有帮助。
-tt
：在每行输出前打印精确到微秒的时间戳。结合
-T
，可以更细致地分析时间序列。
-s
：指定打印字符串的最大长度。默认是32，有时候路径或消息会很长，需要调大。
-v
：输出更详细的信息，比如结构体成员的完整内容。
一个典型的例子，如果你想看看一个程序启动时都打开了哪些配置文件，并且追踪它的所有子进程，同时把结果输出到文件，并且只关注
openat
和
read
系统调用，你可以这样做：
strace -f -o output.log -e trace=openat,read your_program_name
strace 在故障排查中的应用场景？
strace
简直是Linux系统故障排查的瑞士军刀，它的应用场景非常广泛，几乎能覆盖所有与程序和内核交互相关的疑难杂症。我个人觉得，当你对一个程序行为感到困惑，或者它出乎意料地崩溃、卡住时，
strace
往往是第一个应该想到的工具。
首先，权限问题。这是最常见的，比如一个Web服务无法读取某个文件，或者一个用户执行某个脚本报错“Permission denied”。你用
strace
追踪这个程序，很大概率会看到
openat("/path/to/file", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)
这样的输出。
strace
会直接告诉你哪个文件、哪个系统调用失败了，以及失败的原因（
EACCES
、
ENOENT
等），这比盲目猜测要高效得多。
其次，程序卡死或无响应。一个进程突然CPU占用很高但什么都不做，或者干脆就卡在那里不动了。用
strace -p
附加上去，你可能会发现它一直在某个
futex
、
poll
、
epoll_wait
或者
read
系统调用上等待，这通常意味着它在等待某个锁、某个网络事件或者某个文件句柄的数据。通过这些信息，你就能判断是死锁、网络不通还是I/O阻塞了。
再来，性能瓶颈分析。虽然
perf
工具更专业，但
strace -T
也能提供初步的线索。当一个操作很慢时，你可能会看到某个
read
或
write
系统调用花费了数百毫秒甚至几秒。这可能意味着磁盘I/O太慢，或者网络延迟很高。我曾经用它发现过一个程序频繁地进行小块I/O操作，导致性能低下，通过调整I/O策略才解决。
还有，理解未知程序的行为。当你拿到一个第三方二进制文件，或者想搞清楚某个系统命令到底做了什么时，
strace
是最好的“透视镜”。它能让你看到程序打开了哪些库文件、配置文件，连接了哪些IP地址，甚至在哪些目录下创建了临时文件。这对于安全分析、逆向工程或者仅仅是满足好奇心都很有用。
最后，调试程序崩溃。虽然
gdb
是调试崩溃的主力，但有时候
strace
也能提供有价值的线索。一个段错误（Segmentation fault）通常发生在用户空间，但它可能由前一个失败的系统调用引发，或者在尝试访问某个无效内存区域时，
strace
能显示程序在崩溃前最后几个成功的或失败的系统调用，这有助于缩小问题范围。
如何更高效地使用 strace 进行过滤和分析？
strace
的输出量常常是巨大的，尤其是在追踪一个复杂的应用时，如果没有合适的过滤，你可能会被海量的日志淹没。所以，学会高效地过滤和分析输出是使用
strace
的关键。
首先是系统调用过滤。这是最直接的手段，通过
-e trace=
选项来指定你关心的系统调用。例如，如果你只对文件操作感兴趣，可以这样：
strace -e trace=openat,read,write,close,stat,fstat,lstat,access,unlink,rename your_program
如果你在排查网络问题，可以专注于网络相关的系统调用：
Midjourney
当前最火的AI绘图生成工具，可以根据文本提示生成华丽的视觉图片。
454 查看详情 
strace -e trace=socket,bind,connect,listen,accept,sendto,recvfrom,getsockopt,setsockopt your_network_app
strace
甚至支持更高级的过滤表达式，比如
-e trace=!file
可以排除所有文件相关的系统调用，只看其他类型的。或者
-e trace=signal
只看信号相关的操作。
其次，利用管道和文本处理工具。
strace
的输出是标准错误，但你可以将其重定向到标准输出，然后通过管道传递给
grep
、
awk
、
sed
等工具进行二次过滤和分析。
例如，你想追踪一个程序，并且只看其中涉及到
/etc/passwd
文件的操作：
strace your_program 2>&1 | grep "/etc/passwd"
这会将
strace
的所有输出（包括错误信息）都重定向到标准输出，然后
grep
会从中筛选出包含
/etc/passwd
的行。
如果你想统计某个系统调用被执行了多少次，或者某个参数出现的频率，
awk
会非常有用：
strace -e trace=openat your_program 2>&1 | awk '/openat/ {print $2}' | sort | uniq -c
这会列出所有
openat
调用打开的文件路径，并统计每个路径被打开的次数。
第三，输出格式的调整。
-s
选项可以增加字符串的显示长度，这在处理长路径、长消息或者网络数据包时非常重要，避免输出被截断。
-v
（verbose）选项能让
strace
打印出更多结构体内部的细节，这在分析复杂的数据结构时很有用。而
-x
则可以将系统调用的参数以十六进制形式打印出来，对于查看二进制数据或内存地址非常直观。
我通常会先用一个宽泛的
strace
命令跑一遍，把输出重定向到文件。然后用
grep
、
less
等工具在文件中搜索关键字，找到感兴趣的部分。一旦定位到问题区域，再用更精细的
-e trace=
选项重新运行
strace
，或者结合
awk
进行更深入的分析。这种迭代式的分析方法，往往比一开始就试图构建一个完美的
strace
命令更有效率。
strace 的局限性与替代方案有哪些？
尽管
strace
功能强大，但它并非万能，也存在一些固有的局限性。了解这些局限性，能帮助我们选择更合适的工具，或者在特定场景下避免误用。
最显著的局限性是性能开销。
strace
通过拦截系统调用来实现追踪，这意味着它会增加每次系统调用的额外开销。对于系统调用密集型或对实时性要求极高的应用，
strace
可能会显著拖慢程序的执行速度，甚至改变程序的时序行为，这在生产环境中尤其需要谨慎。我记得有一次，在调试一个高性能网络服务时，启用
strace
直接让吞吐量下降了80%，所以生产环境通常不建议长时间开启。
其次，
strace
只能追踪用户空间与内核空间之间的交互。它能告诉你程序调用了
read()
，但无法告诉你
read()
调用返回后，用户空间的程序代码内部发生了什么，比如数据是如何被处理的，哪个函数调用了哪个函数。它看不到用户空间的函数调用栈，也无法深入分析程序内部的逻辑错误，比如一个复杂的算法错误。
再者，输出信息量巨大且可能难以解析。即使使用了过滤，对于一些复杂的应用，
strace
的输出仍然可能像洪水猛兽一般。手动解析这些纯文本日志，尤其是当涉及到复杂的结构体参数或二进制数据时，会非常耗时且容易出错。
鉴于这些局限性，我们常常需要结合其他工具来获得更全面的视角：
ltrace
：追踪库函数调用与
strace
追踪系统调用不同，
ltrace
追踪的是程序对共享库（如glibc）中函数的调用。这对于理解程序在用户空间是如何操作的非常有帮助，比如它调用了哪些
malloc
、
free
、
printf
等库函数。
ltrace
可以作为
strace
的良好补充，一个看“内核门槛”，一个看“库函数门槛”。
perf
：性能分析利器
perf
是Linux内核自带的性能分析工具，它基于事件采样，能够以较低的开销收集各种性能事件，包括CPU周期、缓存命中/未命中、以及系统调用。
perf
可以统计系统调用的频率、耗时，但通常不提供像
strace
那样详细的单个系统调用参数和返回值。它更适合做宏观的性能瓶颈分析和热点函数定位。
eBPF
(Extended Berkeley Packet Filter) /
bpftrace
：现代内核追踪框架这是当前Linux内核追踪领域最先进、最强大的技术。
eBPF
允许用户在内核中运行自定义的小程序，以极低的开销追踪几乎任何内核事件，包括系统调用、内核函数、网络事件、文件I/O等等。
bpftrace
是基于
eBPF
的高级追踪语言，语法简洁，非常适合快速编写复杂的追踪脚本。它提供了比
strace
更强大的过滤、聚合和自定义输出能力，且性能开销远低于
strace
。如果你需要深入到内核级别进行故障排查或性能分析，
eBPF
是未来的方向，但学习曲线相对陡峭。
我个人觉得，
strace
就像一把快速上手的多功能工具刀，在很多日常的、临时的排查场景中都非常有效。但当你需要更深入、更低开销的分析，或者需要理解用户空间内部逻辑时，就得考虑掏出
ltrace
、
perf
，甚至是学习
eBPF
这种“重型武器”了。它们各自有各自的战场，没有最好的，只有最合适的。
以上就是如何在Linux中追踪系统调用 Linux strace调试技巧的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/936934.html
微信扫一扫 
支付宝扫一扫 
