If a process does flock() on a file then dies without unlocking it, does unix
clear that lock or is it left hanging? The man pages and google are silent on
this. Ditto whether LOCK_UN can block?

Also a related question - is there a command line tool that will show/remove
advisory locks and who owns them?

Muttley@dastardlyhq.com writes:
>If a process does flock() on a file then dies without unlocking it, does unix
>clear that lock or is it left hanging? The man pages and google are silent on
>this. Ditto whether LOCK_UN can block?
>
>Also a related question - is there a command line tool that will show/remove
>advisory locks and who owns them?
>

"All locks associated with a file for a given process shall be removed
when a file descriptor for that file is closed by that process or the
process holding that file descriptor terminates. Locks are not inherited
by a child process."

https://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html

(note: flock() is a bsd-ism and is not described by POSIX/SuS).

I'm not aware of any command to show the locks. I'm not aware of any
kernel/filesystem API that provides that visibility.

scott@slp53.sl.home (Scott Lurndal) writes:
> Muttley@dastardlyhq.com writes:
>> If a process does flock() on a file then dies without unlocking it,
>> does unix clear that lock or is it left hanging? The man pages and
>> google are silent on this. Ditto whether LOCK_UN can block?
>>
>> Also a related question - is there a command line tool that will
>> show/remove advisory locks and who owns them?
>
>
> "All locks associated with a file for a given process shall be removed
> when a file descriptor for that file is closed by that process or the
> process holding that file descriptor terminates. Locks are not inherited
> by a child process."
>
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html
>
> (note: flock() is a bsd-ism and is not described by POSIX/SuS).

AFAIK the rules are different for flock, which binds the lock to the
file descriptor (including all copies of it created by dup/fork). So I
think the answer to the original question “it depends” - if the file
descriptor is shared with another process then the lock may not be
released until all the processes with the same file descriptor
terminate.

--
https://www.greenend.org.uk/rjk/

On Sat, 01 Oct 2022 19:21:03 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>Muttley@dastardlyhq.com writes:
>>If a process does flock() on a file then dies without unlocking it, does unix
>>clear that lock or is it left hanging? The man pages and google are silent on
>>this. Ditto whether LOCK_UN can block?
>>
>>Also a related question - is there a command line tool that will show/remove
>>advisory locks and who owns them?
>>
>
>
> "All locks associated with a file for a given process shall be removed
> when a file descriptor for that file is closed by that process or the
> process holding that file descriptor terminates. Locks are not inherited
> by a child process."
>
>https://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html
>
>(note: flock() is a bsd-ism and is not described by POSIX/SuS).

Didn't know, though its available on Linux and MacOS so clearly is fairly
widespread.

>I'm not aware of any command to show the locks. I'm not aware of any
>kernel/filesystem API that provides that visibility.

Pity. Some rainy day I'll have to trawl /proc on linux and see if anything
looks like a list of file locks for a process.

Muttley@dastardlyhq.com writes:
>On Sat, 01 Oct 2022 19:21:03 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:
>>Muttley@dastardlyhq.com writes:
>>>If a process does flock() on a file then dies without unlocking it, does unix
>>>clear that lock or is it left hanging? The man pages and google are silent on
>>>this. Ditto whether LOCK_UN can block?
>>>
>>>Also a related question - is there a command line tool that will show/remove
>>>advisory locks and who owns them?
>>>
>>
>>
>> "All locks associated with a file for a given process shall be removed
>> when a file descriptor for that file is closed by that process or the
>> process holding that file descriptor terminates. Locks are not inherited
>> by a child process."
>>
>>https://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html
>>
>>(note: flock() is a bsd-ism and is not described by POSIX/SuS).
>
>Didn't know, though its available on Linux and MacOS so clearly is fairly
>widespread.

Given OS/x is derived from BSD, that's not unexpected. SVR4 added support
for a bunch of BSD interfaces back in the day as well for portability
reasons, likewise linux.

From the BSD man page:

NOTES
Locks are on files, not file descriptors. That is, file descriptors du-
plicated through dup(2) or fork(2) do not result in multiple instances of
a lock, but rather multiple references to a single lock. If a process
holding a lock on a file forks and the child explicitly unlocks the file,
the parent will lose its lock.

As Richard points out, this implies that the lock persists until the last
reference to the inode is released.

Muttley@dastardlyhq.com writes:
> On Sat, 01 Oct 2022 19:21:03 GMT
> scott@slp53.sl.home (Scott Lurndal) wrote:

[...]

>>I'm not aware of any command to show the locks. I'm not aware of any
>>kernel/filesystem API that provides that visibility.
>
> Pity. Some rainy day I'll have to trawl /proc on linux and see if anything
> looks like a list of file locks for a process.

The (virtual) file /proc/locks lists all currently held file locks. The
pid of the process holding the lock is in the fifth column.

On Sun, 02 Oct 2022 22:18:06 +0100
Rainer Weikusat <rweikusat@talktalk.net> wrote:
>Muttley@dastardlyhq.com writes:
>> On Sat, 01 Oct 2022 19:21:03 GMT
>> scott@slp53.sl.home (Scott Lurndal) wrote:
>
>[...]
>
>>>I'm not aware of any command to show the locks. I'm not aware of any
>>>kernel/filesystem API that provides that visibility.
>>
>> Pity. Some rainy day I'll have to trawl /proc on linux and see if anything
>> looks like a list of file locks for a process.
>
>The (virtual) file /proc/locks lists all currently held file locks. The
>pid of the process holding the lock is in the fifth column.

Thanks.

In article <87o7utgc1d.fsf@doppelsaurus.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@talktalk.net> wrote:
>Muttley@dastardlyhq.com writes:
>> On Sat, 01 Oct 2022 19:21:03 GMT
>> scott@slp53.sl.home (Scott Lurndal) wrote:
>
>[...]
>
>>>I'm not aware of any command to show the locks. I'm not aware of any
>>>kernel/filesystem API that provides that visibility.
>>
>> Pity. Some rainy day I'll have to trawl /proc on linux and see if anything
>> looks like a list of file locks for a process.
>
>The (virtual) file /proc/locks lists all currently held file locks. The
>pid of the process holding the lock is in the fifth column.

There is also a "lslocks" command to list out the data in that file for you.

However, I could not get "lslocks" to show me the full pathname of the
file; it always truncates it. However, the following "find" hack does the
trick (assuming you know, from the "lslocks" output, the inode number and
which filesystem the file is on - e.g., /):

find $fs -xdev -inum $inum -ls 2>/dev/null

(Of course, you could also get the device and inum info directly from
/proc/locks as well)

--
"We should always be disposed to believe that which appears to us to be
white is really black, if the hierarchy of the church so decides."

- Saint Ignatius Loyola (1491-1556) Founder of the Jesuit Order -

Scott Lurndal <scott@slp53.sl.home> wrote:
> Muttley@dastardlyhq.com writes:
>>If a process does flock() on a file then dies without unlocking it, does unix
>>clear that lock or is it left hanging? The man pages and google are silent on
>>this. Ditto whether LOCK_UN can block?
>>
>>Also a related question - is there a command line tool that will show/remove
>>advisory locks and who owns them?
>>
>
>
> "All locks associated with a file for a given process shall be removed
> when a file descriptor for that file is closed by that process or the
> process holding that file descriptor terminates. Locks are not inherited
> by a child process."
>
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html
>
> (note: flock() is a bsd-ism and is not described by POSIX/SuS).
>

FWIW, there's an open proposal to add a flock-like mechanism: File-private
POSIX locks. https://www.austingroupbugs.net/view.php?id=768 (See also
https://lwn.net/Articles/586904/)

Rather than simply standardizing the BSD routine, it mirrors the fcntl
interface with F_OFD_GETLK, F_FD_SETLK, etc, including support for range
locks. It was merged into Linux (kernel, glibc, and musl libc) awhile ago,
but doesn't seem to have been adopted anywhere else, AFAICT.