0

If a process running as (non-root) user A has created a lockfile on disk to reserve a shared resource, what's a good way to seamlessly "hand off" that lock to another process, running as user B, which continues to use the shared resource, and finally removes the lockfile when done?

In an ideal solution (requirements in order of priority):

  1. Noone but users A and B can modify the lock file.
  2. Only user A can create the lockfile.
  3. User A can optionally remove the lockfile after creating it but before the hand-off.
  4. User A can also still optionally remove the lockfile after the hand-off.

The two options I've thought of so far are

  • The lockfile is in a directory writable by a user group containing users A and B. This mostly works, but doesn't meet requirement 2 and becomes less satisfactory if I add a user C in a similar "lock consumer" role as user B.
  • The lockfile is in a directory with the sticky bit set, and user A creates it by making it a hard link to a preexisting file owned by user B. The lockfile is thus always owned by user B. I like that this doesn't require a dedicated user group, but I would prefer to have requirements 2-4 met.
slowdog
  • 6,076
  • 2
  • 27
  • 30
  • 1
    Is this in a server context? e.g., A is the server process. Otherwise this does not make much sense. Here's why. If A holds the resource, then gives it to B, why does A still need to retain control of the resource lock. Can you explain what you are doing, not how you decided to do it - which is what you are asking for help on. – jim mcnamara Jan 04 '12 at 00:28
  • A is waiting for B to release the lock, at which point it will reacquire the lock, and hand it to yet another process. The function of A is to decide in which order a bunch of other processes should receive the lock. – slowdog Jan 12 '12 at 18:30

0 Answers0