lslocks只能看到内核锁表中登记的flock()和fcntl()/lockf()创建的advisory锁，但因内核版本、锁生命周期及归属模糊等问题常“查不到”；最可靠方式是通过/proc/locks结合inode号匹配定位。
lslocks 能看到哪些锁，为什么它经常“查不到”
lslocks 显示的是内核维护的锁表，只包含 flock() 和 fcntl() 创建的 advisory lock（建议性锁）中被内核记录的部分。但它对 flock() 锁的支持依赖于内核版本和锁的生命周期：若进程已 exit 但 fd 未 close，锁可能残留；若进程 fork 后子进程继承了 fd 并未显式解锁，锁仍存在但归属模糊。
常见误判点：
-
lslocks | grep /path/to/file返回空 ≠ 文件没被锁 —— 可能是锁由lockf()设置（lslocks归类为 POSIX，但某些内核不暴露其范围信息） - 输出里 TYPE 列为
FLOCK表示来自flock(2)；POSIX表示来自fcntl(F_SETLK)或lockf() - MODE 列显示
READ/WRITE，带*（如WRITE*）表示该锁正在阻塞其他进程
/proc/locks + inode 是最可靠的定位方式
所有 advisory lock 都会登记在 /proc/locks，且每条记录含 inode 号。只要你知道目标文件的 inode，就能精准匹配——这比路径字符串匹配更可靠，尤其当文件被 hard link 或 rename 过。
操作步骤：
- 用
stat -c "%i" /path/to/file获取 inode 号（比如123456） - 执行
cat /proc/locks | awk '$2 ~ /POSIX|FLOCK/ && $5 == "123456" {print}' - 输出字段含义：
$3是 PID，$4是锁类型（W写锁 /R读锁），$6-$7是字节范围（0 EOF表示全文件）
注意：/proc/locks 不需要 root 权限读取，但普通用户看不到其他用户的 PID 所属命令名，需结合 ps -p PID -o comm= 补全。
fuser -v 和 lsof 的 LOCK 列到底在说什么
fuser -v 和 lsof 不直接读锁表，而是通过扫描 /proc/PID/fd/ 下的符号链接反推“可能持有锁”的进程。它们的可靠性取决于进程是否还开着那个 fd —— 即使锁已被释放，只要 fd 没 close，它们仍会报告“占用”。
lsof 的 LOCK 列值需谨慎解读：
-
N：明确无锁（但仅当进程调用了fcntl(F_GETLK)查询过） -
R/W：表示该 fd 当前被用于读或写，不等于 正在持有读锁/写锁 - 空白或
-：lsof 无法判断锁状态（多数情况） - 真正有意义的是
fuser -v输出中 ACCESS 列的f（open for write）或F（open for read+write），配合你已知的程序行为来推测
所以别单看 LOCK 列下结论；重点看 fuser -v 的 PID 和 ACCESS，再查该进程是否真在用 flock() 或 fcntl() 加锁（比如看它的源码或 strace）。
想确认“此刻能否安全写入”，不要查锁，直接试开
advisory lock 的本质是协作机制。与其花时间逆向分析锁状态，不如用原子操作验证行为意图：
- 非阻塞打开测试：
exec 9>/path/to/file 2>/dev/null && echo "free" || echo "locked"—— 若失败，说明有进程以O_EXCL或排他锁方式占着 - 更贴近业务逻辑：
flock -n /path/to/file -c 'echo ok'，成功即表示你能拿到写锁；失败则说明已有flock()排他锁存在 - 注意：
flock -n是副作用操作，但它是唯一能反映“当前是否可加锁”的真实信号；所有静态扫描工具都只能反映“过去某刻的状态”
真正容易被忽略的是：很多服务（如 rsyslog、logrotate）使用 fcntl() 字节范围锁保护日志文件的特定区域，而非整文件。这种锁在 lslocks 中可见，但在 fuser 或 lsof 中完全不可见 —— 它们只管 fd 是否打开，不管你在哪段加了锁。
