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 _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
