> From: Garrett Rooney [mailto:rooneg@electricjellyfish.net]
>
> Bill Tutt wrote:
>
> > If the watcher process detects an exiting registered process that
hasn't
> >
> > deregistered then the datastore is now suspect. The watcher process
> > must now cause all in process transactions to be aborted.
> >
> > This should probably be accomplished by using some asyncrhonous
> > notification + timeout. If the timeout expires before the other
> > remaining processes exit out, then the watcher process may kill the
> > process explicitly.
> >
> > Once all of the registered processes have either exited with a
useful
> > failure message, or forcefully killed, then the watcher is allowed
to
> > recover the datastore.
>
> how does the watcher process kill the other processes? are we going
to
> install it with the appropriate privs so that it can kill them?
setuid
> binaries give me the creeps...
>
Yes, it needs appropriate privs so that it can kill them if necessary.
We can come up with various schemes to tell the client process to exit
ASAP, but I think that the watcher process still needs to be able to
forcefully kill the client applications.
> also, would we have to have the watcher start up at system start?
that
> adds quite a bit of overhead to the process of creating a repository.
> perhaps it would be possible to have the first svn process that tries
to
> access the repository start the watcher...
>
This is the easiest way to kick start the watcher up.
Well, if the svn process itself started the watcher, then yeah, the
binary would need to be setuid. Ick. I'd rather it not be setuid, and
just run in the correct user security context. (Not to mention fun
portability issues if we use setuid.)
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 19 18:48:11 2002