GNU bug report logs - #56631
flock does not unlock instantly

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 56631 in the body.
You can then email your comments to 56631 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Alexey Kuznetsov <kuznetsov.alexey <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: flock does not unlock instantly
Date: Mon, 18 Jul 2022 13:50:09 +0300

[Message part 1 (text/plain, inline)]

Simple bash script:

#!/bin/bashset -eexec 7<"$0"flock -n 7sleep 60

Will prevent a second instance from being executed (exits instantly). But
if the first instance got killed by 'killall test.sh', the second instance
of the script can be executed only after 60 seconds. First instance of the
script does report being killed instantly, but still does not let me run
the second instance of the script. That makes me think, sleep command not
being killed / handled correctly. Here is a work around example, using the
following script makes it work correctly:

#!/bin/bashset -etrap "kill 0" SIGINT SIGTERMexec 7<"$0"flock -n 7sleep 60


Flock waits until sleep finishes, even when the script holding lock is
killed. Is it a bug or feature?


-- AK

[Message part 2 (text/html, inline)]

Message #8 received at 56631 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Alexey Kuznetsov <kuznetsov.alexey <at> gmail.com>, 56631 <at> debbugs.gnu.org
Subject: Re: bug#56631: flock does not unlock instantly
Date: Tue, 19 Jul 2022 08:14:55 +0200

tag 56631 notabug
close 56631
stop

On 7/18/22 12:50, Alexey Kuznetsov wrote:
> Simple bash script:
> 
> #!/bin/bashset -eexec 7<"$0"flock -n 7sleep 60
> 
> Will prevent a second instance from being executed (exits instantly). But
> if the first instance got killed by 'killall test.sh', the second instance
> of the script can be executed only after 60 seconds. First instance of the
> script does report being killed instantly, but still does not let me run
> the second instance of the script. That makes me think, sleep command not
> being killed / handled correctly. Here is a work around example, using the
> following script makes it work correctly:
> 
> #!/bin/bashset -etrap "kill 0" SIGINT SIGTERMexec 7<"$0"flock -n 7sleep 60
> 
> 
> Flock waits until sleep finishes, even when the script holding lock is
> killed. Is it a bug or feature?

First of all, only sleep(1) is relevant here for the coreutils mailing list;
flock(1) is part of util-linux, and theoretically also the shell could play
into the game.

As I see it, flock(1) calls flock(2) - as can be seen by 'strace -vf ./script':

  [pid 13705] flock(7, LOCK_EX|LOCK_NB)   = 0

Looking at `man 2 flock`:

       Locks created by flock() are preserved across an execve(2).

So it's no surprise that sleep(1) inherits and therefore continues
to hold the lock until its own termination.

As such, I'm closing this bug in the coreutils bug tracker, because sleep(1)
does not do anything different from what any other program would do.
Of course, the discussion can continue.

Have a nice day,
Berny

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.