lsof 默认查不到已删除但仍使用的文件，需用 lsof +L1 或遍历 /proc/lsof 查不到已删除但仍使用的文件？检查 /proc/*/fd

当文件被 rm 删除，但存在部分打开进程时，lsof 默认不会显示“已删除”状态的——它只列出当前路径且可 stat 的文件。真正的线索藏在 /proc

实操建议：用 lsof +L1 强制导入所有链接计数为 0 的文件（即已被删句柄仍开），这是最直接的方式若 +L1 无输出，说明进程没有常规方式打开（比如 mmap 或子进程继承），此时应删除 /proc/[0-9]*/fd/：for p in /proc/[0-9]*; 执行 ls -l "$p/fd/" 2>/dev/null | grep 删除； 完成 | head -20注意：需 root 权限才能读取其他用户进程的 /proc/[pid]/fd/，普通用户只能自己的恢复文件时 cp /proc/[pid]/fd/[fd_num] 直接失败？确认 fd 是否可以且未中断断

从 /proc/[pid]/fd/[n] 复制文件简单启动，但常见失败原因不是权限，而文件本身的状态：或者进程为 O_WRONLY

实操建议：先检查fd状态：ls -l /proc/[pid]/fd/[n]，确认链接目标含已删除字样及权限含r用文件/proc/[pid]/fd/[n]看是否能识别类型；若返回无法打开，该说明fd 已不排除（如写模式打开、或进程已退出）复制时加 dd 更稳妥，避免缓冲问题：dd if=/proc/[pid]/fd/[n] of=recovered.log bs=8k 不要用 cat 管道指示——某些日志类程序会因 SIGPIPE 中断写入，导致恢复不恢复全后文件大小为 0 或不完整检查进程是否仍在追加写入？ 内容，如果原进程仍在向该文件写入（比如日志服务），你复制的只是某个时刻的快照。更糟糕的是，如果进程使用 truncate() 或 lseek(SEEK_END) 后写入，/proc/[pid]/fd/[n] 可能反映的是逻辑偏移取消物理长度。

Pic Copilot

AI时代的顶级电商设计师，轻松打造爆款产品图片下载

实操建议：前恢复优先暂停进程：kill -STOP [pid]（别用TERM/KILL，会关闭fd）用lsof -p [pid]确认fd对应的原始路径和文件大小（SIZE/OFF列是当前偏移量，非总长）若文件是日志，检查其inode是否被轮转工具（如 logrotate）通过copytruncate修改过——情况下，恢复的其实是旧内容，新写入已到新文件后立即恢复stat源fd和目标文件，比对大小和块，差异大说明有稀疏或断断ext4上恢复失败还剩什么招？别忽略extundelete和debugfs的边界能力

lsof + /proc/fd是首选，但它已经进入进程了。一旦进程，退出fd 关闭，内核释放inode链接，就只能靠文件系统层恢复——而ext4默认不保留删除痕迹，extundelete效果有限，尤其启用了extents或journal=ordered。

实操建议：重启分区：umount /dev/sdXN，防止新写入覆盖数据块（若无法卸载，至少停掉写入该的服务）extundelete唯一对未重写的块有效，且不支持ext4的extent 特性（报不支持的范围就放弃）万不得已时用 debugfs 手动查 inode：debugfs /dev/sdXN -R "lsdel"，看是否有未清除的目录项；再用 icat ，提取但需知道原始 inode 号记住：SSD 上 TRIM 之后基本无解，机械盘也得趁早操作——延迟一小时，恢复成功率断崖下降

最容易被忽略的一点：脚本或服务日志会把fd传给子进程（如bash -c 'exec 3>/var/log/app.log'），进程删除了文件，子父进程仍然保留fd。

此时 lsof +L1 可能找不到父进程，但子进程的 /proc/[pid]/fd/ 里藏着关键链接——得顺着 PPid 和 lsof -p [pid] 往上捋两层。