Some notes on
lslocks, the Linux command to list current file locks
Lslocks(8) is the Linux command that you usually use to list current file locks on a machine. Lslocks uses the kernel's /proc/locks to find out about locks, and so is subject to various limitations /proc/locks has. It adds some conveniences to the raw /proc/locks information, but also has some limitations of its own on what information it can present when.
Run as root, the normal
lslocks output looks something like this:
COMMAND PID TYPE SIZE MODE M START END PATH rpcbind 1379 FLOCK 0B WRITE 0 0 0 /run/rpcbind.lock cpuhp/1 13 POSIX READ 0 0 0 /var/mail... cron 2993 FLOCK 5B WRITE 0 0 0 /run/crond.pid blkmapd 389 POSIX 4B WRITE 0 0 0 /run/blkmapd.pid zed 1428 POSIX 5B WRITE 0 0 0 /run/zed.pid zed 1428 POSIX 24B WRITE 0 0 0 /run/zed.state
You normally want to use '
lslocks -u', otherwise some filenames may be
truncated. None are being truncated here, and instead something else is
going on with the '/var/mail...' entry.
The raw kernel information on locks only includes
the inode number of the file being locked. There is no special
kernel interface that
lslocks can use to map these inode numbers
to file names; instead,
lslocks looks up each PID, then goes
through that process's open file descriptors from /proc/<PID>/fd
stat() each one until it finds a match. If there is no such
file descriptor, all that
lslocks can report is the filesystem,
which it prints as '<filesystem>...'.
When running lslocks as root, there are two common cases where
lslocks won't be able to find a matching file descriptor. The first
is what we see in my example output; this is an NFS server with
/proc/locks reporting a lock held by a NFS client machine, and the
process ID is some random kernel process that has no open file
descriptors. The other case you can see is if the listed PID exited
after locking a file descriptor and then passing on the file
descriptor to one or more other processes. In that case, '
<filesystem>' can turn up likely suspect processes and should turn
up at least one open file with the right inode number.
(If you have an NFS server, in general all you can do is '
<filesystem> -inum <whatever> -print'. If you have a specific file you
suspect, you can check its inode number directly with '
ls -li' or
stat' or the like.)
At the moment,
lslocks can also fail to work entirely with an
error message about "failed to parse '<three hex digits>'", because
it expects all filesystem minor numbers in /proc/locks to be two
digits. If you have enough mounted NFS filesystems (and probably
filesystems of certain other types, such as ZFS or tmpfs), their
'minor number' in /proc/locks and /proc/self/mountinfo goes over
255 and so requires three (or more) hex digits. I've filed this as
util-linux issue #1633, so hopefully
it will be fixed at some point (and then make it to 'long term
support' and 'enterprise' Linux distributions a few years after
(In older versions of
lslocks, like the version on Ubuntu 18.04,
lslocks just silently fails to correctly parse /proc/locks and will
report the wrong filesystems for such locks.)
PS: If you run
lslocks as a normal user it can only report filenames
for locks from your own processes, because the /proc/<pid>/fd
subdirectory is only accessible to the process owner. Normally
will report the filesystem for such locks; if you use '
lslocks -i', it
will skip them.