Strace 实战：一行命令看穿任何程序在干什么，排查线上问题的瑞士军刀

一、strace 是什么？原理一句话说清

strace，本质上是一个系统调用和信号的追踪器。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

我们之前聊过，用户空间的程序但凡想跟内核“打个招呼”——无论是读写文件、收发网络数据，还是申请内存——都必须通过“系统调用”这道门。而 strace 就守在这道门的入口，把每一次进出的“访客”信息，包括它的来意（参数）和结果（返回值），都清清楚楚地记录下来给你看。

它的实现原理，依赖的是 Linux 内核提供的 ptrace 机制。没错，就是调试器（比如 GDB）背后用的那套接口。

这里有个关键点：strace 是“只读”的。它只在一旁观察和记录，绝不会去修改程序本身的执行逻辑。因此，用它来诊断线上正在运行的进程，基本上是安全的，不会引发业务异常。当然，任何观测工具都有开销，strace 也不例外，它会让进程执行变慢，所以在生产环境用完记得及时断开，别一直挂着。

二、怎么读 strace 的输出？

先来看一段典型的输出，建立最直观的感受：

openat(AT_FDCWD, “/etc/passwd”, O_RDONLY) = 3
read(3, “root:x:0:0:root:/root:/bin/bash\n”, 4096) = 1764
close(3) = 0
write(1, “Hello\n”, 6) = 6

格式非常固定：系统调用名(参数…) = 返回值。

每一行代表一次系统调用。返回值通常是成功时的结果（如文件描述符、读取的字节数），如果出错，则会返回 -1 并附带具体的错误码说明：

openat(AT_FDCWD, “/no/such/file”, O_RDONLY) = -1 ENOENT (No such file or directory)

掌握了这个基本格式，剩下的就是熟悉那些高频出现的系统调用名。其实完全不用死记硬背，常用的也就那么十几个。

三、最常用的几种用法

用法一：直接启动程序并追踪

strace ./myprogram
strace ./myprogram arg1 arg2

用法二：附加到正在运行的进程

strace -p 1234 # 附加到 PID 1234
strace -p $(pidof nginx) # 附加到 nginx 进程

用法三：只看某类系统调用（最常用）

# 只看文件相关的调用
strace -e trace=file ./myprogram
# 只看网络相关
strace -e trace=network ./myprogram
# 只看进程相关（fork、exec 等）
strace -e trace=process ./myprogram
# 只看指定的几个调用
strace -e trace=read,write,open ./myprogram

用法四：把输出保存到文件

strace -o output.txt ./myprogram
# 输出刷屏时必备，否则根本看不过来

用法五：带时间戳，看耗时在哪

# -T 在每行末尾显示该调用耗时
strace -T ./myprogram
# -t 在行首显示时间
strace -tt ./myprogram # 时间精确到微秒

用法六：统计模式，看哪个调用最多/最慢

strace -c ./myprogram

输出类似这样：

% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
45.23 0.003241 32 101 12 read
30.11 0.002159 43 50 write
15.67 0.001123 11 102 mmap

一目了然，哪个系统调用消耗了最多时间，是排查性能瓶颈的利器。

四、三个真实排查场景

下面这三个场景，都是工作中真实遇到过的，每一个都能靠 strace 快速锁定问题根源。

1. 场景一：程序启动慢，为什么？

程序启动要花5秒，但业务逻辑看起来很简单，时间到底耗在哪里了？

strace -tt -e trace=openat,read ./myprogram 2>&1 | head -50

输出中间出现了这样的行：

10:23:01.123456 openat(AT_FDCWD, “/etc/resolv.conf”, O_RDONLY) = 4
10:23:01.123500 read(4, “nameserver 8.8.8.8\n”, 4096) = 20
10:23:01.123510 close(4) = 0
…
10:23:06.234567 connect(5, {sa_family=AF_INET, sin_port=htons(5432), sin_addr=inet_addr(“10.0.0.1”)}, 16) = -1 ETIMEDOUT

时间戳直接揭示了真相：程序在尝试连接 10.0.0.1:5432（一个 PostgreSQL 数据库端口），等待了近5秒后超时。问题很可能出在错误的数据库配置上。

2. 场景二：程序卡死，在等什么？

用 -p 参数附加到已经卡死的进程上：

strace -p 4521

如果输出只有一行，然后就此静止：

futex(0x7f8b4c001234, FUTEX_WAIT_PRIVATE, 2, NULL

这行输出非常关键。futex 调用中的 FUTEX_WAIT 表示进程正在等待一个锁，而 timeout 参数是 NULL——这意味着它会无限期地等下去。这是死锁的典型特征。

如果程序是多线程的，可以加上 -f 参数追踪所有线程：

strace -f -p 4521

再用 -e futex 过滤一下，就能理清是哪几个线程在互相等待对方持有的锁，从而勾勒出完整的死锁链条。

3. 场景三：程序一直报“Permission denied”，找不到是哪个文件

strace -e trace=openat ./myprogram 2>&1 | grep “EACCES\|EPERM”

输出可能如下：

openat(AT_FDCWD, “/var/run/myapp/myapp.sock”, O_RDWR) = -1 EACCES (Permission denied)

问题瞬间定位：程序试图访问 /var/run/myapp/myapp.sock 这个 Unix socket 文件，但没有权限。用 ls -la 一查，果然文件属主是 root。

五、strace 输出速查图

面对陌生程序的 strace 输出感到茫然？这张速查图能帮你快速建立关联：

六、几个进阶用法，工作中真的用得到

1. 追踪子进程

当程序通过 fork() 创建子进程时，默认的 strace 只会追踪父进程。加上 -f 参数，就能一网打尽：

strace -f -p 1234
# 每行行首会显示 [pid xxxxx]，用于区分不同进程

2. 只追踪失败的调用

大多数成功的调用信息价值有限，我们往往更关心出错的部分：

strace -e trace=all -z ./myprogram
# -z 参数只显示返回值非零（即出错）的调用

3. 配合 grep 快速过滤

# 找出所有打开的文件路径
strace ./myprogram 2>&1 | grep openat
# 找出所有网络连接的目标地址
strace -e connect ./myprogram 2>&1 | grep “sin_addr”
# 找出所有写操作的内容（显示前32字节）
strace -s 32 -e write ./myprogram 2>&1 | grep write

4. -s 控制字符串截断长度

# 默认 strace 只显示字符串的前32个字符
# 使用 -s 参数可以加大显示长度
strace -s 256 ./myprogram

七、和 ltrace 的区别：一个追系统调用，一个追库函数

strace 和 ltrace 经常被放在一起比较，其实它们的分工非常明确：

strace：追踪系统调用。也就是程序进入内核的那些操作，比如 read(), write(), connect()。
ltrace：追踪动态库函数调用。比如程序调用的 printf(), malloc(), strlen() 这些。

在大多数排查场景下，建议先从 strace 入手。因为所有 I/O 操作最终都会落到系统调用上，这里的信息更底层、更准确。而 ltrace 更适合用于分析程序具体调用了哪些库函数，比如验证内存分配行为或字符串处理逻辑。

八、strace 的一个限制

使用 strace 时，有一个重要的技术细节需要注意：它基于 ptrace 实现，每次系统调用发生时，进程都会被暂停两次（进入内核前一次，返回用户空间后一次）。

对于那些系统调用频率极高的程序（比如每秒处理数万次读写请求的服务），使用 strace 追踪会导致明显的性能下降，速度可能会慢上10到50倍。

所以，在生产环境短时间 attach 一下进行诊断是完全可以的，但切忌长时间挂载。如果需要对高性能服务进行低开销的持续观测，可以考虑 eBPF 技术栈下的工具（例如 bpftrace），这才是下一代系统可观测性的方向，我们后续会专门探讨。

九、一份常用命令速查

# 启动并追踪
strace ./program

# 追踪正在运行的进程
strace -p 

# 追踪所有子进程
strace -f ./program

# 只看文件操作
strace -e trace=file ./program

# 只看网络操作
strace -e trace=network ./program

# 只看失败的调用
strace -e trace=all -z ./program

# 显示每次调用耗时
strace -T ./program

# 统计各调用次数和时间
strace -c ./program

# 显示时间戳（精确到微秒）
strace -tt ./program

# 输出到文件
strace -o out.txt ./program

# 加大字符串显示长度
strace -s 512 ./program

# 综合用法：追踪PID，显示时间，输出到文件，追踪子进程
strace -f -tt -o out.txt -p 

十、写在最后

说到底，strace 是一个“开箱即用”的终极诊断工具。它不需要你重新编译程序，不需要修改一行代码，也无需重启服务。更重要的是，它对任何程序都有效，无论你有没有它的源代码。

我们之前讨论的诸多内核概念——文件描述符、Page Cache、信号、系统调用——strace 正是将这些抽象原理变为可视现实的桥梁。看到 openat 就联想到 fd 的三层结构，看到 futex 就明白是锁在底层作祟，看到 write 就想到数据正经过 Page Cache。当知识通过这些工具串联起来，运用时才能真正得心应手。

下次再遇到程序行为诡异、性能不佳或者莫名卡死的情况，不妨先问自己一句：“要不要 strace 一下看看？” 答案，很可能就藏在那些系统调用的轨迹里。