最直接且常用的方法是使用strace命令，它通过ptrace机制捕获进程的系统调用，适用于调试、性能分析和安全审计。
Linux下追踪进程的系统调用，最直接且常用的方法就是使用
strace
命令，它能捕获并显示一个进程或命令所发出的所有系统调用及其参数和返回值。这对于我们理解程序行为、诊断问题、进行性能分析以及甚至进行安全审计都非常有用。它就像给程序装了一个“窃听器”，让我们能一窥它和操作系统内核之间到底在“说”些什么。
解决方案
要追踪一个进程的系统调用，最核心的工具就是
strace
。它的用法非常灵活，既可以用来启动一个新的程序并追踪其所有系统调用，也可以附着（attach）到一个已经在运行的进程上。
基本用法：
追踪新启动的程序：直接在
strace
后面加上你想运行的命令。例如，我想看看
ls -l
这个命令到底做了哪些系统调用：
strace ls -l
你会看到一大串输出，每一行都代表一个系统调用，包括调用名、参数和返回值。这输出量通常会让你感到震撼，一个看似简单的命令背后，其实藏着无数与内核的交互。
追踪正在运行的进程：如果你想追踪一个已经在后台运行的程序，你需要知道它的进程ID（PID）。
strace -p
比如，我有一个程序PID是12345，我想看看它在做什么：
strace -p 12345
这在调试那些“僵住”或行为异常的进程时特别有用，能帮你快速定位它卡在哪里，是不是在等待某个资源，或者某个系统调用一直失败。
输出解读：每一行通常包含：
系统调用名： 比如
openat
,
read
,
write
,
execve
等。参数： 括号里的内容，是传递给系统调用的参数。
strace
会尽量以人类可读的方式显示，比如文件路径、字符串内容等。返回值： 等号后面的数字。通常
0
或正数表示成功，
-1
表示失败。如果失败，
strace
还会显示对应的错误信息（比如
ENOENT (No such file or directory)
）。
通过这些信息，我们就能大致勾勒出程序与内核的交互图谱，从而理解它的运行机制或发现潜在的问题。
strace 的工作原理是什么？它有哪些常用参数？
说白了，
strace
之所以能“监听”系统调用，主要依靠的是 Linux 内核提供的一个叫做
ptrace
的系统调用。
ptrace
允许一个进程（追踪者，也就是
strace
）控制另一个进程（被追踪者），并检查和修改其内存和寄存器。当被追踪进程尝试执行一个系统调用时，内核会暂停它，并通知追踪者。
strace
就在这个暂停的瞬间介入，读取被追踪进程的寄存器来获取系统调用的名称和参数，然后打印出来。等
strace
处理完，它会告诉内核让被追踪进程继续执行系统调用，或者在系统调用返回后再次暂停，让
strace
读取返回值。
这种机制虽然强大，但也有个明显的缺点：每拦截一次系统调用，被追踪进程就得暂停、切换上下文给
strace
，再恢复。所以，
strace
会显著降低程序的执行速度，这在性能敏感的场景下是个需要注意的问题。
常用参数及其妙用：
strace
的参数非常丰富，掌握一些常用的能让你事半功倍：
-c
：这个参数非常实用！它不会显示详细的系统调用日志，而是统计每个系统调用被调用的次数、占用的时间百分比、总耗时等。这对于快速定位性能瓶颈（比如哪个系统调用被频繁调用导致了慢速）非常有帮助。
strace -c ls -l
输出会是一个漂亮的表格，告诉你哪些系统调用是“大户”。
-f
：跟踪子进程。很多复杂的程序会通过
fork()
或
vfork()
创建子进程来完成任务。如果没有
-f
，
strace
默认只追踪父进程。加上
-f
后，
strace
会像“狗皮膏药”一样，紧跟着所有新创建的子进程，确保整个进程树的系统调用都被记录下来。
strace -f make
这在追踪编译过程或者服务器程序时几乎是必选项。
-o
：将
strace
的输出写入指定文件，而不是标准错误输出。这对于长时间运行的程序或者输出量巨大的情况尤其重要，方便后续分析。
strace -o output.log ./my_program
-e
：这个参数是我的最爱之一，因为它能帮你过滤掉大量不关心的信息。
expr
可以是：
易森网络企业版
如果您是新用户，请直接将本程序的所有文件上传在任一文件夹下，Rewrite 目录下放置了伪静态规则和筛选器，可将规则添加进IIS，即可正常使用，不用进行任何设置；(可修改图片等)默认的管理员用户名、密码和验证码都是：yeesen系统默认关闭，请上传后登陆后台点击“核心管理”里操作如下:进入“配置管理”中的&ld
0 查看详情 
trace=set
：只追踪指定集合的系统调用。比如
strace -e trace=open,read,write cat /etc/passwd
就只会显示
cat
命令涉及文件打开、读写操作的系统调用。
!trace=set
：排除指定集合的系统调用。
fault=set
：让指定的系统调用在特定次数后失败，这在测试程序的错误处理机制时非常有用。
abbrev=set
：缩写某些系统调用的输出，让日志更简洁。
strace -e trace=network -f curl example.com
这能让你只关注网络相关的系统调用，对于调试网络程序简直是神来之笔。
-tt
：在每行输出前打印微秒级的时间戳。这能让你更精确地了解每个系统调用发生的时间点，对于分析时序问题很有帮助。
strace -tt ls -l
-T
：显示每个系统调用实际花费的时间。这和
-c
统计的总耗时不同，它显示的是单个系统调用在内核中执行的耗时。结合
-tt
，能让你对程序的实时性能有更直观的感受。
strace -T ls -l
-s
：指定打印字符串的长度。默认情况下，
strace
只打印字符串的前32个字符，如果你的文件路径或字符串内容很长，可能需要增加这个值，比如
-s 256
。
掌握这些参数，你就能像一个老练的侦探一样，从纷繁复杂的系统调用日志中，抽丝剥茧，找到你真正想知道的信息。
除了 strace，还有哪些工具可以用于系统调用追踪？它们各自的优势和适用场景是什么？
虽然
strace
是追踪系统调用的瑞士军刀，但它并非万能，尤其是在性能分析和更深层次的调试上，还有其他更专业的工具。
ltrace：追踪库函数调用
优势：
ltrace
的目标和
strace
有点像，但它关注的是用户空间的库函数调用（比如
malloc
、
free
、
printf
、
strcpy
等），而不是直接的系统调用。很多应用程序的问题，其实是出在对库函数的不当使用上，而非直接的系统调用层面。适用场景：调试内存泄漏：看看
malloc
和
free
的调用情况。分析字符串操作：理解程序如何处理字符串。排查与共享库相关的问题：比如符号查找错误、库函数行为异常。我的看法：
ltrace
就像是
strace
的一个“补充包”，当你怀疑问题出在 C/C++ 标准库函数或者其他第三方库的调用上时，
ltrace
往往能提供
strace
给不了的细节。当然，它同样基于
ptrace
，所以性能开销也很大。
perf：内核事件分析利器
优势：
perf
是 Linux 内核自带的性能分析工具，它的核心优势在于低开销和多维度。
perf
不仅仅能追踪系统调用，还能追踪 CPU 周期、缓存命中/未命中、上下文切换、硬件事件等几乎所有内核可观测的事件。它不是通过
ptrace
机制，而是通过内核的性能计数器和事件探测点（tracepoints）来收集数据，因此对程序性能的影响远小于
strace
。适用场景：性能瓶颈分析： 当你需要找出程序在哪个函数、哪个系统调用、甚至哪一行代码上耗时最多时，
perf
是首选。高吞吐量场景：
strace
无法胜任的生产环境性能分析，
perf
往往能派上用场。系统级性能洞察： 不仅仅是单个进程，
perf
还能提供整个系统的性能视图。追踪系统调用示例：
perf record -e raw_syscalls:sys_enter ./my_programperf report
这会记录所有进入内核的系统调用，然后
perf report
会以交互式界面展示统计结果。
我的看法：
perf
是一个重量级的工具，它的输出不像
strace
那么直观地显示单个系统调用的参数和返回值，更多的是统计和聚合数据。但如果你想深入了解程序和内核的交互效率，找出真正的性能“热点”，
perf
绝对是你的不二之选。它的学习曲线比
strace
陡峭一些，但回报也更高。
eBPF (Extended Berkeley Packet Filter) 工具链：终极可编程追踪框架
优势： eBPF 是 Linux 内核中一个革命性的技术，它允许用户在内核中运行自定义的、沙盒化的程序，以响应各种内核事件（包括系统调用）。eBPF 工具链（如
bpftrace
、
BCC
工具集）提供了无与伦比的灵活性、极低的开销和强大的可编程性。你可以编写非常精细的脚本，只在特定条件下追踪特定的系统调用，甚至修改内核行为。适用场景：深度定制化追踪： 当
strace
和
perf
都无法满足你的特定需求时。实时监控和审计： 实时监控系统调用，发现异常行为。复杂性能分析： 结合多个内核事件进行关联分析。生产环境安全和调试： 由于其低开销，非常适合在生产系统上进行高级故障排除和安全审计。BCC 工具集示例：
BCC
是一个基于 eBPF 的工具集，提供了很多开箱即用的脚本，比如
execsnoop
（追踪进程启动）、
opensnoop
（追踪文件打开）、
syscalls
（统计系统调用）。
sudo /usr/share/bcc/tools/opensnoop -T -p # 追踪指定进程的文件打开操作sudo /usr/share/bcc/tools/syscalls -T # 统计所有系统调用
我的看法： eBPF 是目前 Linux 追踪和可观测性领域最前沿的技术。它非常强大，但学习成本也相对较高，需要对内核有一定的理解。对于日常的系统调用追踪，
strace
足够了；对于性能分析，
perf
很棒；但如果你想成为一个真正的“内核侦探”，能够定制化地深入内核，eBPF 是你迟早要掌握的工具。
总结一下，选择哪个工具取决于你的具体需求：快速查看程序行为用
strace
；想知道库函数调用细节用
ltrace
；分析性能瓶颈用
perf
；需要极致的灵活性和低开销的定制化追踪，那就拥抱 eBPF。
追踪系统调用时可能遇到哪些常见挑战？如何有效分析追踪结果？
追踪系统调用听起来很酷，但在实际操作中，我们常常会遇到一些让人头疼的问题。就像医生给病人做检查，机器是有了，但怎么解读那些密密麻麻的报告，才是真功夫。
常见挑战：
性能开销巨大： 这几乎是
strace
的“原罪”。我遇到过很多次，一个本来运行得好好的程序，一上
strace
就慢得像蜗牛，甚至直接超时。特别是那些 I/O 密集型或者频繁进行上下文切换的程序，
strace
的影响会非常显著。有时候这种性能下降还会掩盖真正的问题，甚至引入新的问题（经典的“海森堡效应”）。输出量爆炸： 随便跑一个稍微复杂点的程序，
strace
的输出文件就能轻松达到几十兆甚至上百兆。想象一下，几百万行的日志，你告诉我怎么看？这简直是信息过载的噩梦。权限问题： 追踪其他用户的进程，或者一些关键的系统服务（比如
systemd
），往往需要
root
权限。在生产环境中，获得
root
权限并非易事，而且操作也需要格外小心。复杂参数解读：
strace
尽力了，但有些系统调用的参数是指针，指向复杂的内存结构。
strace
只能显示内存地址或者部分内容，要完全理解这些参数的含义，你可能需要查阅内核文档，甚至结合源代码来分析。多线程/多进程的混乱： 尽管
strace -f
可以追踪子进程，但当一个程序有大量并发的线程或进程时，它们的系统调用日志会交织在一起，阅读起来非常困难，很难理清逻辑流。
有效分析追踪结果的策略：
面对这些挑战，我们不能蛮干，需要一些策略来提高分析效率：
明确你的目标： 这是最关键的第一步。你是想看程序打开了哪些文件？还是想知道它为什么会崩溃？或者想分析网络连接问题？目标越明确，你就能越精准地筛选信息。善用过滤和统计：
strace -c
： 永远是我的第一选择。先用它跑一遍，看看哪些系统调用被调用得最多，哪些耗时最长。这能快速帮你圈定问题范围。
-e trace=syscall_set
： 针对性地追踪你关心的系统调用。比如，怀疑文件权限问题就只看
openat
,
access
,
stat
；怀疑网络问题就只看
socket
,
connect
,
sendto
,
recvfrom
。
grep
和
awk
：
strace
的输出是文本，所以 Unix 强大的文本处理工具是你的好朋友。
grep "ENOENT"
：查找所有“文件或目录不存在”的错误。
grep "socket"
：查找所有与 socket 相关的系统调用。
awk '/openat/ {print $NF}'
：提取所有
openat
调用的返回值，看看哪些失败了。关注错误码和返回值：
strace
会把系统调用的返回值和对应的
errno
错误信息打印出来。任何返回
-1
的系统调用都值得你重点关注，它通常意味着失败。结合时间戳和耗时分析：
strace -tt
打印微秒级时间戳，帮你理解事件发生的顺序。
strace -T
打印每个系统调用的耗时。如果某个系统调用耗时特别长，那它很可能是性能瓶颈。分段追踪和重现： 如果程序运行时间很长，或者输出量太大，可以尝试只追踪问题发生前后的关键时间段。或者，尽量构造一个能稳定重现问题的最小化场景，这样追踪的范围会小很多。**利用
strace
输出到文件：
以上就是Linux如何追踪进程的系统调用的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/935765.html
微信扫一扫 
支付宝扫一扫 
