lsof-L1查看deletedsocket泄漏方法

本文详解了如何利用 `lsof +L1` 发现并精准定位 Unix domain socket（UDS）资源泄漏——当大量 socket 显示为 `(deleted)` 时，往往意味着路径已被 `unlink()` 但文件描述符未关闭，形成隐蔽的长期驻留泄漏；文章强调不能仅依赖单次 `lsof` 输出，而需结合 `watch` 观察增长趋势、用 `ss -x -p` 关联 inode 与进程、深入 `/proc/pid/fd/` 反查 FD 源头，并特别提醒抽象命名空间 socket（`@` 开头）因不依赖文件系统、`unlink` 无效，其泄漏更难被 `+L1` 捕获，必须通过 `ss` 基线比对或 eBPF 追踪 `sys_socket`/`sys_close` 才能彻底揪出那些藏在初始化逻辑、错误分支或 fork 子进程继承中的 close 遗漏。

为什么 lsof +L1 会显示大量 deleted 的 Unix domain socket

Unix domain socket（UDS）被 unlink() 后，若仍有进程持有其文件描述符，内核不会立即释放 socket 结构体，而是标记为 (deleted) —— 这不是 bug，是正常语义：路径已删，但资源尚被引用。但若长期堆积（比如成百上千），说明有 socket 创建后未正确关闭，或 close() 被遗漏，属于典型的资源泄漏。

关键点：lsof +L1 只显示“链接数为 0 且路径已删除”的文件（含 UDS），但它不区分“刚删、正待回收”和“泄漏驻留”。需结合进程生命周期、FD 生命周期进一步判断。

如何确认是泄漏而非瞬时状态

单次 lsof +L1 | grep unix 输出不可靠。要验证是否泄漏，得看它是否随时间增长、是否绑定到长期运行的进程（如 daemon）、以及 FD 是否持续不释放。

• 用 watch -n 5 'lsof +L1 | grep unix | wc -l' 观察 1–2 分钟内数量是否稳定上升
• 检查对应进程是否本该短命却常驻：比如一个 worker 进程 fork 后未清理父进程创建的 UDS FD
• 注意 lsof 输出中 TYPE 列为 unix、NAME 列含 @（抽象命名空间）或实际路径（如 /tmp/mysock）且标有 (deleted)
• 抽象 socket（@/tmp/xxx）即使路径不存在也可持续存在，lsof +L1 同样捕获——别误以为只有文件系统路径才可能泄漏

定位泄漏源头的实操步骤

核心思路：从 FD 反查代码逻辑，而非仅依赖 lsof。Linux 提供足够线索，但需组合使用。

• 拿到泄漏 socket 的 PID 和 FD 编号（lsof +L1 输出中 PID 和 FD 列，如 1234 12u）
• 进入 /proc/1234/fd/12，执行 readlink . 确认类型（输出类似 socket:[12345678]）
• 用 ss -x -t -n -p | grep 12345678 查该 inode 对应的 socket 状态（-x 表示 Unix socket；-p 需 root 权限才能看到进程名）
• 若进程是自己维护的，检查代码中：
  • 是否每次 socket(AF_UNIX, ...) 都配对 close()？尤其在错误分支、异常跳转、子进程继承场景下
  • 是否调用 unlink() 后忘记 close()？常见于服务启动时清理旧 sock 文件，但残留 FD
  • 是否用 fork() 后未在子进程 close() 父进程传入的 UDS FD？导致子进程退出后 FD 仍被父进程持有

避免抽象 socket 泄漏的特殊注意事项

抽象命名空间 socket（路径以 @ 开头，如 @/tmp/agent）不占文件系统 inode，unlink() 无效，只能靠 close() 释放。很多 C 库封装（如 libdbus、glib）会自动管理，但裸写 bind() + listen() 时极易出错。

• 抽象名本质是内存地址前缀，bind(sock, (struct sockaddr*)&addr, offsetof(struct sockaddr_un, sun_path) + len) 中 len 必须包含 @ 字符本身（即 sun_path[0] = '\0'，后续内容才算抽象名）
• 若 bind 成功但后续未 close，该 socket 会一直存活，且 lsof +L1 不显示它（因为没调用 unlink，无 deleted 状态）——所以 +L1 漏掉的抽象 socket 泄漏更隐蔽，得靠 ss -x | wc -l 对比基线值
• Go、Python 等语言 runtime 通常封装了 UDS 生命周期，但若用 syscall 或 ctypes 直接调用，同样要手动 close

真正难排查的不是 “有没有泄漏”，而是 “哪个路径创建后没 close” —— 尤其当 socket 在初始化阶段创建、却被整个生命周期复用时，日志和堆栈都难以覆盖。建议在关键路径加 setsockopt(..., SO_PASSCRED, ...) 日志，或用 bpftrace hook sys_socket 和 sys_close 做 FD 生命周期追踪。

今天关于《lsof-L1查看deletedsocket泄漏方法》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！