improper locking with -w

[poeml]

migrated from Google Code issue tracker
poeml, 2015-06-15
https://code.google.com/p/withlock/issues/detail?id=1

Reported by bmwiedemann, Feb 20, 2014
What steps will reproduce the problem?
l=test.lock ;
withlock -w100 $l "date +%s; sleep 0.3" & sleep 0.2 ;
withlock -w100 $l "date +%s; sleep 5" & sleep 0.5 ;
withlock -w100 $l "date +%s; sleep 5" ; wait

What is the expected output? What do you see instead?
expected: lock should prevent things from running at the same time.
actual: 2nd and 3rd call run in parallel

What version of the product are you using? On what operating system?
all affected (on openSUSE-12.3 among others)

Please provide any additional information below.
also filed at https://bugzilla.novell.com/show_bug.cgi?id=864785

[poeml]

Actually fixed a year ago, just not tracked here. https://bugzilla.novell.com/show_bug.cgi?id=864785 was updated then.

So, closing!

[bmwiedemann]

bug is still there

[poeml]

So the actual bug is the race condition between the time the lockfile is open()ed, and the lock on it is set. Especially if there is a waiting time configured, this time window is huge. Even without, the possibility for the same race condition to occur is there.

What I didn't understand at first is that this bug was blatantly covered behind the even bigger bug that the lockfile was cleanup-removed even if it was never locked by a withlock run. Okay!

I'm wondering. If the goal is to never never have two same jobs running, then the cleanup should simply not happen at all. The lockfiles should just stay in the filesystem. It doesn't harm anyone after all. Then the race condition is gone (unless a sysadmin removes the lockfile by other means.

On the other hand, if the goal is to just prevent cronjobs from stacking up, and have a "clean" filesystem, and one wants to check by lockfile-presence whether a job is running, then the cleanup should stay.

Maybe both could be possible, by configuration?