Re: cvs as a heartbeat client (questions)

[Todd Denniston]

Larry Jones wrote:
> 
> 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.
> 

The man page on my slackware 8.1 system indicates the linux killall sends
SIGTERM, but it is probably a good idea for portability to do SIGTERM
explicitly then.

<SNIP>
> 
> > 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.)

Cool. In a quick test I did earlier today, if ',filename,' existed the (now)
second checkin from the user would fail, but the ',filename,' was removed and
the third checkin would work.
 From your comment it seems like a good idea just to leave those files until
they cause an error, so the users know _something_ is up.

<SNIP> 
> > 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.

I think you guy's have done a very good job of bullet-proofing it, I had to
think hard on what could cause trouble and 4 above was the only thing that
really popped out.  If I can do 2 during root requested fall overs it should
reduce the chance the systems will run in to trouble.

> 
> -Larry Jones

Thanks for the informative response.

-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter