Re: liblockfile L_PID behavior and use of stat atime
Rob Browning <rlb@defaultvalue.org> writes:
> Someone reported a bug against lockfile-progs, and while
> investigating I noticed a couple of things about liblockfile that
> didn't seem quite right.
After further investigation, it looks like a lockfile created on a
noatime (or relatime?) filesystem, without specifying L_PID, can never
go stale. The problem is in lockfile_check().
Does anyone have any bright ideas about how to fix that?
One suggestion was to just test in lockfile_check() to see if the
atime changes between two accesses, but that would require sleeping
for "long enough" between the attempts. Of couse how long is long
enough would depend on the atime resolution of the underlying
filesystem.
I suppose that approach would fix the problem, but would it be
acceptable to slow down lockfile_check(), lockfile_create(), etc. by
that much, and if so, how could you portably and quickly determine the
atime resolution? I have the impression that for some filesystems,
the resolution can be fairly coarse.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Reply to: