lsof +L1 显示大量 deleted Unix domain socket 表明存在资源泄漏：路径已删但文件描述符未关闭，需结合 watch 观察增长趋势、ss 查 inode、/proc/fd 反查代码确认 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 生命周期追踪。
