[CVS] pidfile support

[Henrique de Moraes Holschuh]

On Mon, 16 Dec 2002, Rob Siemborski wrote:
> > 1. There is no support for updating the pidfile. Thus, the lock is acquired
> > only after forking, which means we lost the controlling terminal by the time
> > we can complain about not being able to acquire a lock, and that we have
> > already tried to go daemon and thus whatever is trying to start master is
> > NOT told that we failed.
> 
> I don't think you can fix this in a perfect way, giving unix locking
> semantics (well, atleast fcntl).

Well, I don't have SuS3 here, but according to SuS2, you're correct. fcntl
alone won't do it.

> [A] lock and write pidfile
> [A] fork and create [B] (which doesn't hold a lock on the file)
> [B] attempt to reacquire lock on pidfile, FAIL since A doesn't have it
> [A] exit(success)
> [B] exit(failure)

Which is clearly broken and suboptimal :-)  I'm (un)?lucky that linux likes
to run A first, then B (after the fork), so I just got an useless race in
there that avoids the always-fail situation...

> I don't think the BSD flock() semantics even help us here (hold lock

It won't.   We will have to transfer the lock to B without a
race-condition.  That means IPC, or signals, or something like that...

One other possile way to do it, is to use the _presence_ of the pidfile with
a running process with that pid (specified in the pidfile) as the lock.  We
remove the file on exit (clean or otherwise), and we ignore it at startup if
there is no such a process running in the system.

[A] 1. stat pidfile
    2. file exists?
    2a (yes) - read pid from file, kill(pid,0) it
    2a1      - kill says process exists? fail to start if so
    2a2      - lock file, fail to start if locking fails
    2b (no)  - create locked file, fail to start if locking fails
    3. write pid to file (just in case)
    4. unlock it, and fork
[B] 1. lock pidfile
[B] 2. write pid to it
[B] 3. do master work()
[A] 5. exit

There are minor race conditions if whatever is trying to start master is a
forkbomb, and the system has a small pid space, but that's far better than
the current scheme.

Unless I overlooked something, that is :)

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh