strace和dtruss这两个命令对不少开发者来说可能听过名字但真正用顺手的并不多。我刚开始接触系统调用跟踪时也只觉得它们是高级版的黑盒调试器直到有一次线上服务莫名卡死、日志里什么都没留下靠着strace一步步揪出问题才真正意识到这类工具的价值。这篇文章不打算写成命令手册的复读机而是结合我实际排查问题的经历把strace和dtruss的核心思路、常用场景、参数选择以及那些文档里不会明说的坑一次讲清楚。不管你是做后端服务、写系统工具还是搞移动端调试只要你的程序跑在Linux或macOS上这两个命令都值得花半小时掌握。它们能帮你回答一个很朴素的问题程序到底在执行什么卡在了哪里为什么失败。1. 系统调用跟踪到底是什么为什么这两个命令值得学1.1 一次离谱的卡死排查让我认清了系统调用的价值先讲个我自己的例子。之前维护过一个内部工具定时任务偶尔会整个挂住既不退出也不报错CPU占用还很高。第一反应是上gdb看调用栈结果栈顶停在某个锁等待上看不出谁抢了锁。后来想到用strace看它到底在等什么系统调用结果发现进程反复在执行futex调用参数里带着FUTEX_WAIT等一个地址的值变化而这个地址对应的线程一直没释放锁。顺着这个线索很快就定位到是某次异常分支没走解锁逻辑。整个过程里strace没有直接告诉我锁没释放但把线程卡在哪个系统调用、等了多久、谁在等全都摊开在眼前了。类似的故事在排查文件删不掉端口被占用程序启动失败等场景里几乎天天发生。这类问题有个共同特征应用日志里看不到错误但内核层有明确的返回码。strace干的事情就是在应用和内核之间架一个摄像头记录每一次系统调用的参数和返回值。dtruss则是在macOS上干同样的事只是底层机制不同。1.2 用户态与内核态的边界外交系统调用的运行机制要理解strace和dtruss的价值先得理解程序运行的基本模型。普通应用程序跑在CPU的用户态能访问的资源和权限受限而读写文件、创建进程、收发网络数据这类操作必须通过内核来完成。应用层调用read()、write()、open()这类函数时实际上会在底层触发对应的系统调用CPU切换到内核态由内核代执行再把结果返回给用户态。这个过程有点像你打电话给餐厅订餐你只负责说出需求系统调用的参数接电话的人内核负责传达给后厨、确认订单并告诉你结果返回值。如果订单没成接电话的人会告诉你一个原因——可能是菜品卖完了文件不存在可能是电话占线资源被占用。strace和dtruss就是给这通电话加了录音。它们能记录你说了什么系统调用名与参数、对方回了什么返回值与错误码、这通电话打了多久耗时、打电话的频率统计信息等。了解了这个机制你就能明白这类工具不会告诉你业务逻辑为什么错但能告诉你内核层面的每一步到底发生了什么而这往往就是问题真正的根源。1.3 strace与dtruss的关系同一思路下的两副面孔strace诞生于Linux世界几乎所有主流Linux发行版都自带或可通过包管理器安装。dtruss则是基于macOS的DTrace框架封装的一个工具默认随系统附带位于/usr/bin/dtruss主要服务于macOS和BSD系系统。两者解决的问题一致但实现路径不同strace使用ptrace系统调用直接拦截被跟踪进程的系统调用dtruss基于DTrace动态插桩技术在内核中动态注入探针不需要像ptrace那样完全控制被跟踪进程。从命令形态上看strace -p 1234可以动态附加到运行中的进程dtruss -p 1234同样支持。但dtruss在macOS上往往需要root权限且默认输出格式和strace有明显差异。更关键的是strace的参数体系更丰富比如按系统调用类型过滤、统计汇总、跟踪子进程等dtruss在参数覆盖面上略逊一筹但胜在与macOS系统本身的兼容性更好。所以如果你主要在Linux服务器上排查问题学strace是第一优先级如果你搞macOS端的开发调试dtruss就是日常必备。文章后面我会把两个命令的对比和适用场景拆开细讲。2. 核心参数与输出解析先把工具用明白2.1 strace的常用参数和输出格式这次讲透strace的完整参数很多但日常高频用到的其实就那么十几个。-f表示跟踪由目标进程创建的子进程排查多进程程序时几乎必开-e trace网络表示只看网络相关的系统调用常见的过滤值有文件文件操作类、进程进程管理类、网络、信号、内存等-o指定输出文件-T显示每个系统调用的耗时-t在输出行前加时间戳方便对齐日志。还有几个容易被忽略但实用的参数-c会汇总统计每个系统调用的次数和总耗时很适合做性能粗筛-p附加到指定进程比如strace -p 9876-e traceopenat,read,write这种写法可以精确指定要跟哪几个系统调用避免输出爆炸。-s参数控制字符串类型参数的最大输出长度默认32字节遇到长路径或长URL时经常需要调大。输出格式长这样openat(AT_FDCWD, /etc/localtime, O_RDONLY|O_CLOEXEC) 3 read(3, TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 4096) 4096 close(3) 0第一列是系统调用名和参数右边是返回值。返回值如果为-1后面跟的errno才是关键比如ENOENT表示文件不存在EACCES表示权限不足ECONNREFUSED表示连接被拒绝。排查时养成习惯看到失败的系统调用后立刻去查对应的errno含义比死盯业务日志高效太多。2.2 dtruss的用法差异与需要注意的细节dtruss最常用的参数是-c统计各系统调用次数、-e显示错误返回值、-f跟踪子进程、-p附加进程。与strace最大的差异在于默认输出格式dtruss输出的第一列往往是进程ID和用户态/内核态切换的耗时如dtrace的TIMESTAMP同时系统调用名后面跟着一大串十六进制参数看起来没有strace那么直观。一个典型输出dtrace: description syscall::openat:entry matched 1 probe PID COMMAND FD ARGS 1234 curl 24 openat(0x01000000, 0x7ff7bfef2f00, 0x0, 0x0) 3 0这里ARGS列打印的是寄存器参数和栈上的参数不像strace那样直接显示解析后的路径名。想让dtruss显示更易读的路径字符串可以加-u参数把用户态地址解析为字符串但可靠性取决于当时进程的用户态内存是否可读。这一点上dtruss的调试体验确实不如strace方便。另一个需要注意的坑是在macOS上运行dtruss绝大多数情况下都要root权限。在较老版本的macOS上DTrace还受安全限制约束新版系统里虽然默认可用但依然建议用sudo dtruss执行避免权限不足导致无法附加到进程。2.3 输出信息怎么看从一堆日志里抓重点不管是strace还是dtruss输出量都可能非常巨大。一个简单的ls命令就能产生几十条系统调用更不用说跑个网络服务了。所以学会抓重点是基本素养。我的习惯是分三步走先看有没有返回值是-1的系统调用有就先圈出来这是错误的主线。再看高频调用的分布用-c做统计比如read、write、futex这类调用占了绝大多数时间往往说明程序在IO或线程同步上花了大头。最后结合业务场景定位。比如启动阶段失败重点看openat、execve、mmap运行中卡住重点看futex、poll、epoll_wait、nanosleep网络超时重点看connect、sendto、recvfrom的返回值和耗时。这个思路同样适用于dtruss只不过要把第2步的-c换成dtruss的-c输出dtruss的统计输出包含系统调用次数、耗时等格式和strace略有不同。3. 实操过程从看不懂到用得顺的完整案例3.1 场景一程序启动即崩溃用strace定位缺库问题遇到过不少同事说程序一启动就段错误不知道怎么办。这类问题如果发生在Linux下用strace跟一遍启动流程往往几秒就有结论。假设有一个叫myapp的二进制启动直接崩strace -f -o /tmp/myapp.strace ./myapp-f跟踪所有子进程-o把输出写到文件里避免屏幕刷屏。打开输出文件找到最后几条系统调用往往就是崩之前的临终现场openat(AT_FDCWD, /lib/x86_64-linux-gnu/libssl.so.3, O_RDONLY|O_CLOEXEC) -1 ENOENT (No such file or directory) write(2, error while loading shared librar..., 40) 40这两行已经把问题说透了程序在加载libssl.so.3时找不到文件。后续write到stderr的信息也印证了这一点。看完这个输出直接ldd ./myapp确认依赖路径然后把对应的so装好或调整LD_LIBRARY_PATH问题解决。这个场景里的关键点在于strace能看清楚启动流程中每个文件被打开的位置和结果比用ldd盲猜高效得多。如果换成dtruss命令变成sudo dtruss -f -o /tmp/myapp.dtruss ./myapp同样看最后几条open/invoke记录也能发现问题。不过dtruss对macOS的崩溃后路径显示有时不完整所以我会优先看错误返回为-1的记录再配合-e参数把所有错误的调用圈出来。3.2 场景二网络请求卡住用strace追踪系统调用找原因有次排查一个HTTP客户端请求卡住的问题日志显示请求发出后一直没响应但服务端说没收到请求。用strace挂上客户端进程后看到了完整链路socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_TCP) 3 connect(3, {sa_familyAF_INET, sin_porthtons(8080), sin_addrinet_addr(10.20.30.40)}, 16) -1 EINPROGRESS (Operation now in progress) poll([{fd3, eventsPOLLOUT}], 1, 30000) 1 ([{fd3, eventsPOLLOUT}]) getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) 0connect返回EINPROGRESS是正常现象表示连接建立中随后poll等待可写事件。问题就出在poll返回了POLLOUT但实际连接并没有成功建立因为接下来getsockopt取到的SO_ERROR是0看起来一切正常。直到后续第一次sendto才暴露问题sendto(3, ..., 0) -1 EPIPE。排查到最后发现是这个客户端和服务器之间的网络拓扑中某个中间设备对SYN包设置了静默丢弃导致TCP三次握手一直没完成客户端一直等。单靠业务日志根本看不清这条TCP连接的建链状态而strace把connect、poll、getsockopt每一步都记录下来了。如果你用的是dtruss查找网络调用时可以加-e traceconnect,recvfrom,sendto类似的过滤dtruss也支持按系统调用名精确过滤写法是-e connect或-e syscall::connect。macOS下网络类问题同样可以按照这个思路定位只是参数解析上需要多花点功夫。3.3 场景三用strace统计信息做性能粗筛有时候并不是程序出错而是程序变慢。这时候可以用strace -c做一次系统调用级别的粗筛。比如我有个文件批处理脚本处理一批文件越来越慢先不急着优化业务代码跑一遍统计strace -c -f ./batch_process.py结束后输出类似% time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 78.26 4.132000 413200 10 read 11.25 0.594000 5940 100 openat 5.41 0.285000 2850 50 write一目了然read虽然只调用了10次但总耗时占78%每次平均413毫秒。这说明程序在读取大数据块时严重阻塞大概率是磁盘IO瓶颈。顺着这个方向去查文件系统的IO性能、缓存设置、是否有大量随机读比盲目优化代码快得多。这个场景在dtruss下同样支持sudo dtruss -c -f ./batch_process能输出类似统计。不过dtruss的统计信息颗粒度比较粗没有strace按系统调用类型分层的细粒度做性能分析时建议先用top、sample这类工具粗筛再用dtruss精校。3.4 场景四macOS下用dtruss排查文件读写问题有朋友遇到一个诡异问题macOS上的程序读取一个配置文件偶尔会读到旧内容怀疑是文件缓存问题。在Linux下可以用strace -e traceopenat,read跟踪换到macOS就得上dtrusssudo dtruss -e openat,read -p 4567附加到进程后输出会显示PID COMMAND FD ARGS 4567 myapp 12 openat(0x01000000, 0x7ff7bfef2f00, 0x0, 0x0) 13 0 4567 myapp 13 read(0xD, 0x7ff7bfef2e00, 0x400) 1024 0看到read返回1024字节但应用层可能因为内部缓冲逻辑没有用上这次读取的内容。这种问题用dtruss确认内核层面确实读到了新数据之后就可以放心把矛头指向应用层——是缓存策略没刷新。换句话说dtruss能把数据到底有没有读到这个事实摆清楚避免在错误层次上反复猜。macOS下dtruss对sudo的依赖比Linux更严格如果你发现dtruss执行时报权限错误先用sudo -i切换root环境试试。另外dtruss在较新macOS版本上对进程附加偶尔会报dtrace: failed to initialize dtrace之类的错误遇到的话检查系统是否限制了DTrace的用户权限必要时调整安全设置后再试操作前先确认当前系统环境不要盲目改动。4. 常见问题与排查技巧实录4.1 踩坑记录strace输出太大把磁盘写满我刚用strace时干过一次蠢事直接strace -f -o /tmp/trace.log ./service没做任何过滤结果服务跑了十几分钟后日志文件好几个GB把磁盘占满服务直接挂了。后来学乖了高流量进程一律先用-c统计模式快速跑几十秒确定热点系统调用后再精确过滤跟踪。总结下来的输出控制原则能用过滤条件就尽量用-e trace文件-e trace网络或精确指定系统调用名。必须全量输出时用-o写文件而不是打到屏幕避免终端卡死。加上-s限制字符串长度长URL和长路径会瞬间刷爆日志。配合timeout命令控制跟踪时长比如timeout 30 strace -f -o /tmp/trace.log ./program防止忘记手动停止。dtruss同样存在输出量大的问题用-e过滤和-o输出是基本操作。4.2 为什么都要sudo才能跑权限与安全机制strace在Linux下跟踪他人进程时通常需要ptrace权限很多发行版默认允许root执行普通用户能否跟踪取决于/proc/sys/kernel/yama/ptrace_scope的配置。如果值为1普通用户只能跟踪子进程要跟踪其他用户进程就得root或改变配置。dtruss在macOS上几乎默认就需要root因为DTrace框架本身是个内核级调试机制权限要求天然高。建议所有跨进程跟踪操作都直接上sudo避免频繁遇到权限报错。还有个容易被忽略的点安全软件或容器环境可能阻止ptrace。如果你在容器里跑strace发现什么都没有输出先检查容器是否给了CAP_SYS_PTRACE权限没有的话加上--cap-addSYS_PTRACE再试。4.3 进程已经跑起来了还能不能跟踪日常排查中经常是程序已经跑起来了才知道需要跟踪。strace和dtruss都支持附加到运行中的进程sudo strace -p 1234 -e trace文件 -o /tmp/attach.log sudo dtruss -p 1234 -e openat,read -o /tmp/attach.dtruss这里有个技巧如果-p附加时报Operation not permitted除了权限问题也可能是进程自身设置了PR_SET_DUMPABLE一种避免被追踪的自我保护机制这类进程即使root也可能附加失败。另外strace附加时的-f要谨慎因为一旦加了-f它会跟踪目标进程后续创建的所有子进程输出量可能瞬间增大。我一般先不加-f确认主进程的调用链后再决定是否展开。4.4 几个容易被忽略但超级实用的细节第一strace对已经崩溃或退出的进程无能为力但-o输出的最后几行往往就是崩溃前的遗言。如果程序启动闪退别急着改代码先strace看输出。第二-y参数可以打印文件描述符关联的文件路径。比如read(3, ...)不知道3对应哪个文件加-y后输出变成read(3/etc/hosts, ...)省去猜的功夫。dtruss输出里FD列也有类似信息不过显示格式差异较大。第三-z参数可以只显示成功调用的末尾静默模式-Z则只显示失败的调用排查错误时用-Z能大幅降低噪声。dtruss的-e参数也有类似效果它会过滤掉返回成功的系统调用只展示有错误的。第四strace的-xx能显示转义后的字符串跟二进制协议调试时很有用。dtruss对二进制内容的输出一直比较弱遇到这类需求建议换成tcpdump或Wireshark之类的抓包工具别在系统调用层面硬啃。第五-i参数在strace中会打印指令指针地址配合addr2line可以把崩溃位置定位到具体函数这在没有调试符号的环境里是个绝招。dtruss没有直接对应的参数但配合atos在macOS上可以实现类似目的。以我自己的经验一开始接触strace和dtruss时不要想着把所有参数背下来先记住附加进程-p、跟子进程-f、过滤-e、统计-c、写文件-o这几个就够应付大多数场景了。等真遇到需要细致定位的问题再回头翻参数的文档印象会深刻得多。这两个命令看起来不起眼但用好的话能帮你把很多玄学问题变成有据可查的逻辑问题排查效率直接翻倍。