* flock in 2.20.1 can no longer lock the file it will execute @ 2011-11-14 6:23 Mike Frysinger 2011-11-16 13:13 ` Karel Zak 0 siblings, 1 reply; 5+ messages in thread From: Mike Frysinger @ 2011-11-14 6:23 UTC (permalink / raw) To: util-linux, Michal Kubecek, Petr Uzel [-- Attachment #1: Type: text/plain, Size: 780 bytes --] i've been using a trick with flock to add locking to all of my shell scripts. basically, i take a lock on the shell script itself: flock -eon ./test.sh ./test.sh with <=util-linux-2.20, this has worked fine. but starting with 2.20.1, i now get -ETXTBSY (on ext4, but i doubt that matters): $ echo '#!/bin/sh' > test.sh $ chmod a+rx test.sh $ ./flock -eon ./test.sh ./test.sh ./flock: ./test.sh: Text file busy the only commit made to flock.c between 2.20 and 2.20.1 is this: commit 75aaee08f06b92d119ed827c53d1af5474eb16ff flock: make flock(1) work on NFSv4 and indeed, reverting that made my life happy again. reading the small patch shows the obvious flaw: you can't open a file for O_RDWR and attempt to execute it at the same time. -mike [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: flock in 2.20.1 can no longer lock the file it will execute 2011-11-14 6:23 flock in 2.20.1 can no longer lock the file it will execute Mike Frysinger @ 2011-11-16 13:13 ` Karel Zak 2011-11-16 15:25 ` Mike Frysinger 0 siblings, 1 reply; 5+ messages in thread From: Karel Zak @ 2011-11-16 13:13 UTC (permalink / raw) To: Mike Frysinger; +Cc: util-linux, Michal Kubecek, Petr Uzel On Mon, Nov 14, 2011 at 01:23:38AM -0500, Mike Frysinger wrote: > i've been using a trick with flock to add locking to all of my shell scripts. > basically, i take a lock on the shell script itself: > flock -eon ./test.sh ./test.sh > > with <=util-linux-2.20, this has worked fine. but starting with 2.20.1, i now > get -ETXTBSY (on ext4, but i doubt that matters): > $ echo '#!/bin/sh' > test.sh > $ chmod a+rx test.sh > $ ./flock -eon ./test.sh ./test.sh > ./flock: ./test.sh: Text file busy > > the only commit made to flock.c between 2.20 and 2.20.1 is this: > commit 75aaee08f06b92d119ed827c53d1af5474eb16ff > flock: make flock(1) work on NFSv4 > > and indeed, reverting that made my life happy again. reading the small patch > shows the obvious flaw: you can't open a file for O_RDWR and attempt to execute > it at the same time. Hmm... maybe we can add a new --read-write command line option for NFS guys rather than be smart with access(). The regression is unacceptable. Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: flock in 2.20.1 can no longer lock the file it will execute 2011-11-16 13:13 ` Karel Zak @ 2011-11-16 15:25 ` Mike Frysinger 2011-11-21 16:35 ` Karel Zak 0 siblings, 1 reply; 5+ messages in thread From: Mike Frysinger @ 2011-11-16 15:25 UTC (permalink / raw) To: Karel Zak; +Cc: util-linux, Michal Kubecek, Petr Uzel [-- Attachment #1: Type: Text/Plain, Size: 1675 bytes --] On Wednesday 16 November 2011 08:13:21 Karel Zak wrote: > On Mon, Nov 14, 2011 at 01:23:38AM -0500, Mike Frysinger wrote: > > i've been using a trick with flock to add locking to all of my shell > > scripts. > > > > basically, i take a lock on the shell script itself: > > flock -eon ./test.sh ./test.sh > > > > with <=util-linux-2.20, this has worked fine. but starting with 2.20.1, > > i now > > > > get -ETXTBSY (on ext4, but i doubt that matters): > > $ echo '#!/bin/sh' > test.sh > > $ chmod a+rx test.sh > > $ ./flock -eon ./test.sh ./test.sh > > ./flock: ./test.sh: Text file busy > > > > the only commit made to flock.c between 2.20 and 2.20.1 is this: > > commit 75aaee08f06b92d119ed827c53d1af5474eb16ff > > flock: make flock(1) work on NFSv4 > > > > and indeed, reverting that made my life happy again. reading the small > > patch shows the obvious flaw: you can't open a file for O_RDWR and > > attempt to execute it at the same time. > > Hmm... maybe we can add a new --read-write command line option for > NFS guys rather than be smart with access(). The regression is > unacceptable. i wonder what happens if you attempt to take a read-only lock on nfs. do you get back an error ? or does it fail silently at runtime in the nfs layers ? if the former, one solution might be to open the file, attempt to grab the lock, and if the flock() fails, retry the whole thing but with O_RDWR instead. int rw_flags = O_RDONLY; ... retry: ... current open logic which uses new rw_flags var ... ... if flock fails, and rw_flags == O_RDONLY, then set rw_flags to O_RDWR and jump back to retry ... -mike [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: flock in 2.20.1 can no longer lock the file it will execute 2011-11-16 15:25 ` Mike Frysinger @ 2011-11-21 16:35 ` Karel Zak 2011-11-21 20:11 ` Mike Frysinger 0 siblings, 1 reply; 5+ messages in thread From: Karel Zak @ 2011-11-21 16:35 UTC (permalink / raw) To: Mike Frysinger; +Cc: util-linux, Michal Kubecek, Petr Uzel On Wed, Nov 16, 2011 at 10:25:46AM -0500, Mike Frysinger wrote: > On Wednesday 16 November 2011 08:13:21 Karel Zak wrote: > > On Mon, Nov 14, 2011 at 01:23:38AM -0500, Mike Frysinger wrote: > > > i've been using a trick with flock to add locking to all of my shell > > > scripts. > > > > > > basically, i take a lock on the shell script itself: > > > flock -eon ./test.sh ./test.sh > > > > > > with <=util-linux-2.20, this has worked fine. but starting with 2.20.1, > > > i now > > > > > > get -ETXTBSY (on ext4, but i doubt that matters): > > > $ echo '#!/bin/sh' > test.sh > > > $ chmod a+rx test.sh > > > $ ./flock -eon ./test.sh ./test.sh > > > ./flock: ./test.sh: Text file busy > > > > > > the only commit made to flock.c between 2.20 and 2.20.1 is this: > > > commit 75aaee08f06b92d119ed827c53d1af5474eb16ff > > > flock: make flock(1) work on NFSv4 > > > > > > and indeed, reverting that made my life happy again. reading the small > > > patch shows the obvious flaw: you can't open a file for O_RDWR and > > > attempt to execute it at the same time. > > > > Hmm... maybe we can add a new --read-write command line option for > > NFS guys rather than be smart with access(). The regression is > > unacceptable. > > i wonder what happens if you attempt to take a read-only lock on nfs. do you > get back an error ? yes, EIO > if the former, one solution might be to open the file, attempt to grab the > lock, and if the flock() fails, retry the whole thing but with O_RDWR instead. > > int rw_flags = O_RDONLY; > ... > retry: > ... current open logic which uses new rw_flags var ... > > ... if flock fails, and rw_flags == O_RDONLY, then set rw_flags to O_RDWR > and jump back to retry ... Good idea, implemented and tested (git pull to get the change). It seems it works with your example as well as with NFSv4. Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: flock in 2.20.1 can no longer lock the file it will execute 2011-11-21 16:35 ` Karel Zak @ 2011-11-21 20:11 ` Mike Frysinger 0 siblings, 0 replies; 5+ messages in thread From: Mike Frysinger @ 2011-11-21 20:11 UTC (permalink / raw) To: Karel Zak; +Cc: util-linux, Michal Kubecek, Petr Uzel [-- Attachment #1: Type: Text/Plain, Size: 232 bytes --] On Monday 21 November 2011 11:35:43 Karel Zak wrote: > Good idea, implemented and tested (git pull to get the change). It > seems it works with your example as well as with NFSv4. latest git now works for my scripts too :) -mike [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-11-21 20:11 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-11-14 6:23 flock in 2.20.1 can no longer lock the file it will execute Mike Frysinger 2011-11-16 13:13 ` Karel Zak 2011-11-16 15:25 ` Mike Frysinger 2011-11-21 16:35 ` Karel Zak 2011-11-21 20:11 ` Mike Frysinger
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox