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 to 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, ' lsof <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 ' find <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 that).

(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 lslocks will report the filesystem for such locks; if you use ' lslocks -i ', it will skip them.