Re: cvs as a heartbeat client (questions)

[Larry Jones]

Todd Denniston writes:
> 
> 2) on linux will a `killall cvs` cause cvs (as server for :ext: &/or
> :pserver:)to cleanup and exit nicely or is there a particular signal I should
> pass to killall? What I want is to be able to essentially tell cvs is "I know
> the file system is leaving, sync self and bail".

I'm not sure what signal killall sends by default on Linux, but on
systems that I'm familiar with it sends SIGKILL which is kill with
extreme prejudice -- the signal cannot be caught or ignored so it would
give CVS no chance to cleanup and exit nicely.  SIGTERM is the canonical
"please go away" signal; CVS should honor it.

> 3) if a `killall cvs` is done on the the server processes what is the likely
> output on a cvs client on a remote system? Will the client automatically try
> again in a few seconds? Will it cause data corruption in the users sandbox?

The client will report an error from the server and quit.  The user must
run it again to finish whatever operation was interrupted.  There should
not be any corruption in the sandbox (or the repository!), but the
repository may well be in an inconsistent state sine the user might have
been in the middle of a commit and thus the repository would have new
versions of some files but not of others.

> 4) worst case, if a user is committing and cvs is not stopped before the lower
> level device goes away (probably from a power fail),  a partial or even full
> ',filename' new file could exist.
>       a) correct???

Yes.

>       b) does anything need to be done in one of these worst cases, (re)move 
> file?

It's possible that permission problems could keep another user from
comitting changes to that file, but the original user should be able to
commit it without any problems.  (And you probably don't want anyone
else to commit changes before the interrupted commit is completed
anyway.)

> 5) is there a more efficient way of locking the repository than creating all
> the `#cvs.rfl' in all the sub directories of all the repositories? That is, is
> there a single file I can create that blocks access to each repo for the whole
> repo, instead of what is suggested for backup?

No.  CVS locking is per-directory.

> 6) am I just over killing the effect removal of the disk from cvs will have on
> the server processes?

I don't think so, losing access to the disk is a very serious problem
and one that has almost certainly not been heavily tested.  However, CVS
was designed to be as bullet-proof as possible.

-Larry Jones

My brain is trying to kill me. -- Calvin