根本原因是network namespace基于bind mount实现，/var/run/netns/下文件仅为挂载点；进程退出但挂载未清理时，内核仍持有namespace，导致ip netns list显示残留却无法删除。
为什么 ip netns list 显示一堆残留 namespace 却删不掉？
根本原因是：Linux 的 network namespace 是基于 bind mount 实现的，/var/run/netns/ 下的文件只是挂载点。如果进程已退出但挂载未清理，namespace 仍被内核持有，ip netns list 就会列出它，但 ip netns delete 会报 Cannot remove namespace file: No such file or directory 或静默失败。
常见诱因包括：容器运行时异常退出、unshare --net 测试后忘记清理、CI/CD 中 ip netns exec 段错误导致挂载点残留。
关键判断依据：ls -l /var/run/netns/ 看到类似 netns_foo -> /proc/12345/ns/net 的软链，而 ps -p 12345 显示进程不存在 —— 这就是典型残留。
用 find + readlink 批量识别真实残留 namespace
不能只靠 ip netns list 输出，得逐个检查挂载点指向的 /proc/ 是否还存在：
find /var/run/netns -type l -exec sh -c 'for f; do pid=$(readlink "$f" | sed "s|/proc/\\([0-9]\\+\\)/ns/net|\\1|"); [ -z "$pid" ] || [ ! -d "/proc/$pid/ns" ] && echo "$f"; done' _ {} \;- 该命令只输出那些软链指向已消亡进程的 namespace 文件路径（如
/var/run/netns/testns） - 注意：部分系统（如旧版 CentOS 7）
/var/run是 tmpfs，重启即清，但长期运行的服务器必须主动清理
安全删除残留 namespace 的三步操作
确认残留后，不能直接 rm，否则可能破坏正在使用的 namespace（比如 Docker 容器还在用同名挂载点）。必须先 unmount 再删文件：
- 对每个残留路径
$ns_path，执行sudo umount "$ns_path"—— 失败说明有进程正用它，跳过 - 成功 unmount 后，再
sudo rm "$ns_path" - 最后验证：
ip netns list | grep -q "$ns_name" && echo "still there" || echo "gone" - 可封装为一行清理命令（加
-f避免交互）：sudo umount /var/run/netns/* 2>/dev/null; find /var/run/netns -type l -delete 2>/dev/null，但慎用，建议先用上一步识别出的列表精准操作
写成可复用脚本要注意的三个细节
一个可靠脚本必须处理边界情况，不是简单循环 ip netns list：
- 避免误删：检查
/var/run/netns/是否为目录，防止路径不存在时报错中断 - 兼容不同挂载方式：有些环境用
mount --bind而非符号链接，需补充mount | awk '/^ns:/ {print $3}'扫描实际挂载点 - 权限问题：
umount和rm必须用sudo，但脚本开头应检测是否已有 root 权限，没权限则直接 exit 并提示sudo ./clean-netns.sh - 示例核心逻辑片段：
if [ -d /var/run/netns ]; then for ns in /var/run/netns/*; do [ -L "$ns" ] || continue target=$(readlink "$ns") if [[ "$target" =~ ^/proc/[0-9]+/ns/net$ ]] && ! [ -d "${target%/ns/net}" ]; then sudo umount "$ns" 2>/dev/null && sudo rm "$ns" fi done fi
真正麻烦的是那些被长期占用却无对应进程的 namespace —— 往往是内核模块或驱动残留，这种得查 ls -la /proc/*/ns/net 2>/dev/null | grep ，但绝大多数场景只需处理挂载点即可。
