bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#56631: flock does not unlock instantly


From: Bernhard Voelker
Subject: bug#56631: flock does not unlock instantly
Date: Tue, 19 Jul 2022 08:14:55 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]