info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cvs as a heartbeat client (questions)


From: Todd Denniston
Subject: Re: cvs as a heartbeat client (questions)
Date: Fri, 02 Apr 2004 14:10:31 -0500

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

It does not seem to be honoring SIGTERM (as well as I would like anyway).

I issue `killall -SIGTERM cvs` twice prior to removing the disk and cvs is
still running after the disks are removed. 
I also just tried sending `killall -SIGTERM cvs` twenty times from the command
line and had no effect on the server for an :ext: checkout, not even when it
switched sub directories.

while doing an update, :ext: method, it takes 2 or 3 calls to `killall
-SIGTERM cvs` before the server process is stopped. If the update is caught
before it starts processing files, i.e., before the client prints 'cvs server:
Updating .', it terminates quickly.



If I am somewhat more patient, after ~30 seconds from the kill command, cvs
[any command] will terminate.  It looks like the client processes another
30-50 files after the server is given the SIGTERM, which seems like a lot of
files to me.

I am going to change my plan a little and issue the SIGTERM a couple of times,
sleep 30 seconds and then issue `killall -9 cvs`, so if there is some kind of
emergency we are able to go down in under a minute.

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

-SIGTERM gives:
cvs [server aborted]: received termination signal
cvs [checkout aborted]: end of file from server (consult above messages if
any)

-9 gives:
cvs [checkout aborted]: end of file from server (consult above messages if
any)



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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]