• Advisory file locking

    From Muttley@dastardlyhq.com@21:1/5 to All on Sat Oct 1 15:01:53 2022
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Lurndal@21:1/5 to Muttley@dastardlyhq.com on Sat Oct 1 19:21:03 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Kettlewell@21:1/5 to Scott Lurndal on Sat Oct 1 23:18:04 2022
    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/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Muttley@dastardlyhq.com@21:1/5 to Scott Lurndal on Sun Oct 2 14:17:22 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Lurndal@21:1/5 to Muttley@dastardlyhq.com on Sun Oct 2 15:04:21 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rainer Weikusat@21:1/5 to Muttley@dastardlyhq.com on Sun Oct 2 22:18:06 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Muttley@dastardlyhq.com@21:1/5 to Rainer Weikusat on Mon Oct 3 07:56:40 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kenny McCormack@21:1/5 to rweikusat@talktalk.net on Mon Oct 3 11:48:12 2022
    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 -

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Ahern@21:1/5 to Scott Lurndal on Mon Oct 3 17:52:18 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)