strace 在选定 Linux 进程与内核之间的边界上观察系统调用和信号，不需要重新构建程序，就能展示尝试访问的路径、参数、返回值和错误。应用日志漏掉操作时，这些证据很有帮助；但它不会暴露每个用户态决定，也不会自动指出哪次失败调用导致最终结果。正确诊断仍需把边界行为与程序控制流程联系起来。
坏掉的样子
父进程可能启动子进程执行真正工作。只追踪父进程，会看到等待和退出，却漏掉子进程中的文件打开失败。使用 -f 跟随新建进程可以扩大范围，但不会自动追踪所有既有兄弟进程或请求涉及的外部服务。被选中的进程集合，本身就是证据范围的一部分，不能只看到主命令被追踪就认定全部参与者都在视野内。
错误返回不一定是根因。程序经常尝试可选文件、搜索多个位置，并从预期失败中恢复。找到第一条 ENOENT，或者退出前最后一次不成功调用，都不能替代理解应用控制流程。真正需要回答的是，这个返回值如何影响正在调查的操作。相同错误名在不同分支里，可能分别代表正常探测和不可继续的条件。
过滤与计时也会改变解释。把输出限制为文件打开，就有意排除了网络及其他活动。追踪还可能改变调度和延迟，尤其影响系统调用频繁的工作负载，没有通用固定降速倍数。过滤后的记录看起来正常，不能证明被排除操作成功，也不能证明没有追踪器时会出现完全相同的竞争时序。
快速验证
把脚本保存为 straceprobe.py，在安装 strace 的一次性 Linux 环境中运行 python3 straceprobe.py。实测使用 Linux 6.12.76、Python 3.11.2 和 strace 6.1。样本启动自己的无害程序，使用临时配置路径，并要求环境允许追踪新启动子进程：
from pathlib import Path
from tempfile import TemporaryDirectory
import subprocess,sys
child=r'''
from pathlib import Path
import sys
try:Path(sys.argv[1]).read_bytes()
except FileNotFoundError:pass
try:content=Path(sys.argv[2]).read_bytes()
except FileNotFoundError:sys.exit(7)
assert content==b'configured'
'''
parent='import subprocess,sys\nchild='+repr(child)+'\nsys.exit(subprocess.run([sys.executable,"-c",child,*sys.argv[1:]]).returncode)'
with TemporaryDirectory(prefix='xbcatm-strace-') as directory:
root=Path(directory);optional=root/'optional.conf';required=root/'required.conf'
command=[sys.executable,'-c',parent,str(optional),str(required)]
def trace(name,follow):
output=root/(name+'.trace')
args=['strace']+(['-f'] if follow else [])+['-tt','-T','-yy','-s','200','-e','trace=openat,close','-o',str(output),'--',*command]
result=subprocess.run(args,capture_output=True,text=True,timeout=10)
return result.returncode,output.read_text(),result.stderr
code,unfollowed,error=trace('parent-only',False)
assert code==7 and str(required) not in unfollowed,(code,error)
code,followed,error=trace('with-children',True)
assert code==7,(code,error)
def calls(text,path):return [line for line in text.splitlines() if 'openat(' in line and '"'+str(path)+'"' in line]
for path in [optional,required]:
lines=calls(followed,path);assert len(lines)==1 and 'ENOENT' in lines[0],lines
print('failing run:',lines[0])
print('without -f the parent trace misses the child opens; following the child exposes both missing paths')
required.write_bytes(b'configured')
code,recovered,error=trace('recovered',True);assert code==0,(code,error)
assert 'ENOENT' in calls(recovered,optional)[0]
assert ' = -1 ' not in calls(recovered,required)[0]
print('successful run:',calls(recovered,optional)[0])
print('successful run:',calls(recovered,required)[0])
print('a successful application can contain ENOENT; the fixture distinguishes optional lookup from required configuration')
summary=root/'summary'
result=subprocess.run(['strace','-f','-c','-e','trace=openat','-o',str(summary),'--',*command],capture_output=True,text=True,timeout=10)
assert result.returncode==0,result.stderr
text=summary.read_text();assert 'openat' in text and 'total' in text
print('syscall summary:\n'+text)
应用子进程先尝试可选配置文件，允许它不存在；随后读取第二份必需配置，缺失时以状态七退出。父进程返回子进程状态。这构成一份完整失败案例，原因可以直接从样本代码查明，不依赖工作区中根本不存在的占位应用。判断追踪结果时，已知控制流程提供了可以比较的依据。
第一次追踪不启用 -f。命令返回七，但父进程的打开记录没有必需路径。启用跟随后重跑，能看到子进程对可选和必需路径的打开，两者都返回 ENOENT。这个对照证明，即使命令整体失败已经可见，错误选择进程范围仍会隐藏关键操作，不能据父进程记录缺少某路径就断言没有访问尝试。
随后只创建必需文件，并写入正确内容。下一轮返回零，必需路径打开成功，可选查询却仍然返回 ENOENT。这个成功案例刻意反驳“任何错误行都证明应用失败”的判断：两次相同错误在程序逻辑里承担不同角色。修复后保留的正常失败，比单独列出错误日志更能说明真正的恢复条件。
追踪包含 -tt 时间戳、-T 调用经过时间和 -yy 描述符上下文；有限字符串长度足以显示受控路径，-o 则把追踪输出与应用输出分开。脚本断言真实返回码和目标打开结果，没有仅凭追踪文件存在就视为验证完成。记录生成、预期行为出现与最终任务成功，是需要分别检查的结果。
最后使用 -c 汇总恢复后应用的选定 openat 调用和错误，计数也包含运行时启动工作。因此总数不是业务请求数量，默认汇总计时也不能等同应用完整墙钟时间。精确次数和时长会随运行时及环境变化。理解样本时应关注必需路径恢复与返回状态的关系，而不是把本次汇总数字当成所有环境的固定常量。
沿假设追踪到真实结果
应从具体操作出发，确定哪些进程执行它，再选择能够保留所需证据的过滤条件。文件、网络和进程追踪回答不同问题；依赖位于当前视野之外时，再扩大选择范围，同时保持工作负载足够小，便于解释。记录越多并不自动越有价值，关键在于证据能否支持或否定当前假设。
使用 -p 附加时，需要核对进程身份和追踪权限。即使 PID 存在，凭据、安全策略、命名空间关系或容器配置，也可能拒绝访问。本样本在没有额外容器能力的情况下追踪新建子进程，不代表已经证明可以附加其他系统上的任意既有服务。环境许可与工具参数正确，是不同的前提。
捕获的参数和数据应适合当前调查。追踪可能包含路径、请求内容或凭据，因此应使用受控输入，并限制保留材料。把追踪与应用行为对应起来，复现拟议修复，再检查最终结果。本例中可选错误仍存在而应用恢复成功，正好提供了这种因果对照，避免把日志里最醒目的一行误当成结论。
