Linux lslocks 怎样查看进程持有的文件锁

Linux 可以用 lslocks --pid PID 查看指定进程关联的文件锁，并用 --output 明确列出 PID、锁类型、读写模式及文件路径。分析时要同时看 MODE 是否带星号：等待申请的锁不能当成已经持有的锁。对于 OFD 等与打开文件描述关联的锁，一个 PID 也未必代表全部持有者。

util-linux 官方项目地址：https://www.kernel.org/pub/linux/utils/util-linux/

下面把一次“任务似乎在等文件”的排查拆成只读观察：先明确进程，再理解锁记录，最后保存采集结果。本文只给原创命令示例，没有在制作中执行，也不将任何 PID 或图示当作真实故障现场。

从目标 PID 开始只读查询

先在业务环境中确定目标进程 PID。下面的 24680 只是占位示例，必须替换；不要照抄它就认为对应自己的服务。

# 在 Linux 上查看工具版本和本机支持的选项、列名。
lslocks --version
lslocks --help

# 替换为目标 PID；显式指定列，避免依赖默认表格。
target_pid=24680
lslocks --pid "$target_pid" --output COMMAND,PID,TYPE,MODE,START,END,PATH

命令不带文件路径参数来限定单个文件；这里使用 PID 缩小观察范围。指定输出列方便同事阅读，也减少工具默认列变化影响。长路径可在本机支持时增加 --notruncate。相关参数见 lslocks 上游手册。

我更倾向于先保留完整锁类型和范围，再按业务文件解释。仅见一个路径就下结论，容易把普通打开文件、应用自己的标记文件与内核文件锁混在一起。这是排查方法的取舍，不是声称本文经历过某次生产事故。

把持锁行和等待行分开理解

若本机支持 BLOCKER 列，可以把它加入原来的列清单。记录为等待状态，说明这条申请尚未获得相应锁；并不说明该进程没有其他已持有的锁。排查时应按行判断，而不是给整个 PID 简单贴一个“持锁”或“等待”的标签。

底层文件锁记录包含类型、设备与 inode、字节范围等信息，参见 /proc/locks 文档。若要对照两个记录是否指向同一对象，应保留设备和 inode 线索，而不是只凭显示出来的文件名。

路径和 PID 不完整时看什么

路径缺失不等于锁不存在。显示中的省略可能来自列宽，也可能是路径无法解析；前者可以尝试不截断显示，后者需要检查观察账号的访问权限与 /proc 可见范围。不要在路径缺失时自动把记录丢弃，再把剩余结果宣称为完整清单。

OFD 锁与打开文件描述关联，可以被多个进程共享，不能总按“一个锁只有一个进程拥有”建模。某些记录的 PID 可能为 -1；本机若支持 HOLDERS 列，它可以提供更多持有者信息。单纯按目标 PID 筛选不是所有共享锁关系的完整答案。

容器中也要说明观察位置。/proc/locks 的列表受挂载 /proc 所关联的 PID 命名空间影响；容器里看到的结果不能直接当成宿主机完整列表。查询时间不同，锁也可能已经释放，因此两次结果变化本身不构成工具失效的证据。

将查询接入一次性采集脚本

若本机支持 JSON 输出，可以保存固定列的结构化结果。下面脚本只采集一次，不包含自动解除锁或终止进程的动作；旧版工具若不支持选项，应根据本机帮助调整，不伪造空结果代替失败。

#!/usr/bin/env bash
set -eu

# 要求调用者提供 PID；输出文件存在时拒绝覆盖，便于保留记录。
target_pid="${1:?用法：collect-locks.sh PID}"
case "$target_pid" in
  ''|*[!0-9]*) echo "PID 必须为数字" >&2; exit 2 ;;
esac
set -C

# 显式列名并保留命令错误；失败时不要把部分文件解释为正常采集。
lslocks --json --pid "$target_pid" \
  --output COMMAND,PID,TYPE,MODE,START,END,PATH \
  > "locks-${target_pid}.json"

结合时间、观察位置和目标服务身份保存记录更有用。脚本中的数字检查只判断输入形式，不证明 PID 对应服务仍然存活，更不避免 PID 在之后被重用。自动化系统应把命令退出状态、采集文件和业务进程身份一起处理。

这类结果适合作为排查线索，不适合直接触发“发现写锁就杀进程”的策略。正常业务本就可能持有写锁；是否异常要结合预计持锁时长、任务阶段和应用自己的错误记录判断。

常见问题

没有输出就说明进程没有任何锁吗？

只能说明本次查询在当前可见范围和筛选条件下没有列出相关记录。应用层互斥、锁文件约定、共享 OFD 关系和瞬时锁都可能需要另作解释。

目录里有 .lock 文件，为什么 lslocks 查不到？

“存在一个命名为 .lock 的文件”与“对文件建立内核锁”是不同机制。有的应用只检查文件是否存在，不能用 lslocks 是否列出来判断该约定是否正在使用。

lslocks 能直接释放文件锁吗？

本文查询命令用于观察。释放应由应用按自己的生命周期完成；不要把路径删掉当成可靠的解除内核锁操作。