On 07/26/2018 07:01 AM, Brian J. Murrell wrote: > On Thu, 2018-07-26 at 05:48 +0200, Matt Darfeuille wrote: >> >> As illustrated by this lingering thread, issues that are only present >> on >> one platform makes me moved away from OpenWRT/LEDE. > > The platform is not the problem. The platform is just providing the > tools. > > Or are you suggesting that the "lock" tool on OpenWRT/LEDE is actually > buggy? Given that it's just a wrapper around flock() that seems > unlikely. But I'm happy to be proven wrong if you can provide a > reproducer for the bug that I can submit upstream. As much testing as > I have done with the "lock" tool it operates as expected when used as > expected. > > Given the evidence, it seems like the file being locked is getting > removed before the lock is released. > > A reboot of my router this morning has reproduced the situation and > this is what I see: > > # ps -ef | grep lock > root 2700 2666 0 07:13 ? 00:00:00 lock > /etc/shorewall-lite/state/lock > root 3234 1 0 07:13 ? 00:00:00 lock > /etc/shorewall-lite/state/lock > > # lsof -n -p 3234 > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > lock 3234 root cwd DIR 0,15 656 258 / > lock 3234 root rtd DIR 0,15 656 258 / > lock 3234 root txt REG 254,0 308533 1786 /bin/busybox > lock 3234 root mem REG 254,0 77040 213 /lib/libgcc_s.so.1 > lock 3234 root mem REG 254,0 601968 402 /lib/libc.so > lock 3234 root 0u CHR 1,3 0t0 317 /dev/null > lock 3234 root 1u CHR 1,3 0t0 317 /dev/null > lock 3234 root 2u CHR 1,3 0t0 317 /dev/null > lock 3234 root 3u REG 0,14 5 61617 > /etc/shorewall-lite/state/lock (deleted) > lock 3234 root 13w FIFO 0,8 0t0 1732 pipe > > # cat /proc/2700/fd/3 > 3234 > > # strace -f -p 3234 > strace: Process 3234 attached > restart_syscall(<... resuming interrupted syscall_516 ...>) = 0 > nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffcd900) = 0 > nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffcd900) = 0 > nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffcd900) = 0 > nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffcd900) = 0 > nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffcd900) = 0 > nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffcd900) = 0 > nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffcd900) = 0 > nanosleep({tv_sec=1, tv_nsec=0}, ^Cstrace: Process 3234 detached > <detached ...> > > # strace -f -p 2700 > strace: Process 2700 attached > flock(3, LOCK_EX^Cstrace: Process 2700 detached > <detached ...> > > Hrm. Given: > > g_havemutex="lock -u ${lockf} && rm -f ${lockf}" > > Observe this particular set of operations: > > tty1# lock /tmp/mylockfile > tty1# [has the lock and returns] > tty2# lock /tmp/mylockfile > [blocks waiting for locker1 to release the lock as we can see:] > # lsof | grep /tmp/mylockfile > lock 1249 root 3u REG 0,13 5 352778 > /tmp/mylockfile > lock 1250 root 3u REG 0,13 5 352778 > /tmp/mylockfile > tty1# lock -u /tmp/mylockfile && rm -f /tmp/mylockfile > tty1# [returns, releasing the lock to tty2] > tty2# [returns from blocked state, now holds the lock] > # lsof | grep /tmp/mylockfile > lock 1404 root 3u REG 0,13 5 352778 > /tmp/mylockfile (deleted) > tty3# lock /tmp/mylockfile > tty3# [wait, what? it returns even though tty2 has the lock!] > # lsof | grep /tmp/mylockfile > lock 1404 root 3u REG 0,13 5 352778 > /tmp/mylockfile (deleted) > lock 1439 root 3u REG 0,13 5 362181 > /tmp/mylockfile > > So at this point both tty2 and tty3 believe they have the lock and have > returned, allowing them to do their work on top of each other. > > I don't think a process can simply remove the lock file just because it > has released it's lock on it. It can only be removed if there are no > more outstanding locks on it. Or just don't remove it. lock seems to > function perfectly fine with the file pre-existing. > > I'm not sure I can draw a line from this problem to the stale locks > problem, but it's probably a good thing to fix before continuing to try > to debug the stale locks problem. >
Brian, Can you point me to online documentation that describes how this 'lock' utility is supposed to work? Thanks, -Tom -- Tom Eastep \ Q: What do you get when you cross a mobster with Shoreline, \ an international standard? Washington, USA \ A: Someone who makes you an offer you can't http://shorewall.org \ understand \_______________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users