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

Re: Introduction of a "lock" group

On Mon, Aug 15, 2011 at 06:00:50PM +0100, Roger Leigh wrote:
> On Mon, Aug 15, 2011 at 05:35:54PM +0100, Colin Watson wrote:
> > On Mon, Aug 15, 2011 at 04:11:49PM +0100, Roger Leigh wrote:
> > > Are these any other downsides we need to consider?  One issue is the
> > > existence of badly broken programs³, which make stupid assumptions
> > > about lockfiles.
> > 
> > What about programs that need to write lock files which are already
> > setgid something else?  I don't have an example off the top of my head,
> > but it would surprise me if there were none of these.
> IIRC Fedora have a setgid lock locking helper for this, which lockdev
> uses internally.  I'd need to check the details on a Fedora VM.  IIRC
> it checks if you have write perms on the device being locked, and so
> individual programs don't need to be setgid lock unless they are not
> using liblockdev.

The use of an external helper means this is significantly slower than an
open(…, O_CREAT) + flock(). While this works for some workloads, it
doesn't for all.

As my other question was: /var/lock (or /run/lock) was a good solution
for transient, "cheap" locks for coordination between some cooperative
programs. It would be ideal if we have a recipe for this after the
permissions change.


Attachment: signature.asc
Description: Digital signature

Reply to: