strace可直接暴露90%系统级错误，关键在首行失败调用；需用-z只显失败、-e trace=openat,connect等聚焦入口、-s 256防路径截断、-o保存后grep "= -1"快速定位。
直接用 strace 看报错，90% 的系统级错误（比如 “No such file or directory”、“Permission denied”、“Connection refused”）在第一行失败调用里就暴露了，不用翻日志、不用猜路径。
报错时怎么快速定位到那条失败的系统调用
别等程序跑完再看输出——失败往往发生在开头几行。关键不是“看到所有调用”，而是“立刻抓住 -1 返回值”。strace 默认把失败调用标为 = -1 ENOENT (No such file or directory) 这种格式，括号里就是人类可读的错误名。
- 加
-z：只显示失败调用，避免被几百行成功的read或clock_gettime淹没 - 加
-e trace=open,openat,connect,accept：聚焦最常出错的几个入口，尤其openat在现代程序里比open更常用 - 加
-s 256：防止路径被截成"/etc/confi..."，真实路径缺一字符都可能找不到问题 - 如果报错一闪而过，立刻加
-o /tmp/err.log保存，然后grep "= -1" /tmp/err.log
为什么明明报了 Permission denied 却看不到 open()？
因为程序可能根本没走到 open 那步——权限检查发生在更早的系统调用上。比如：
-
statx("/path/to/file", ...)返回= -1 EACCES：说明连路径元数据都读不了，可能是父目录无 x 权限 -
access("/path/to/file", F_OK)失败：程序在打开前主动做了权限预检 -
mkdirat(AT_FDCWD, "/missing/dir", ...)失败：不是文件不存在，而是上级目录不可写
别只盯着 open，-e trace=file 包含的 statx、access、chmodat 同样关键。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
strace 显示 connect() = -1 ECONNREFUSED，但 netstat 说端口开着
这通常不是网络问题，而是目标进程没在监听你连的那个地址或协议。常见原因：
- 程序绑定了
127.0.0.1:8080，你却连localhost:8080（解析成 IPv6 ::1）或0.0.0.0:8080 - 服务只监听 IPv4，你用 IPv6 地址连；或者反过来
-
connect()成功返回后，紧接着write()就= -1 EPIPE：对方进程已崩溃，TCP 连接被 RST，但connect()已完成
验证方法：strace -e trace=connect,sendto,recvfrom -f -p $(pidof your_service)，看它实际 bind 在哪个地址。
容器里 strace 报 Operation not permitted 怎么办
这不是权限不够，是容器默认禁用了 CAP_SYS_PTRACE 能力。宿主机上 root 用户也一样被拦。
- Docker 启动时加
--cap-add=SYS_PTRACE，否则strace -p必然失败 - Kubernetes Pod 中需在
securityContext.capabilities.add显式添加 - 别试图改
/proc/sys/kernel/yama/ptrace_scope——容器内该路径通常只读，且改了也没用 - Alpine 镜像里
strace可能没预装，先apk add strace再试
真正容易被忽略的是：即使加了 cap，如果容器用了 seccomp profile，也可能拦截 ptrace 系统调用——这时 strace 会静默失败，连错误提示都没有。
