Re: cvs as a heartbeat client (questions)
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
Re: cvs as a heartbeat client (questions)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Todd Denniston wrote: 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. This really shouldn't be the case and I cannot reproduce it. I would really love to see a reproducible case if you can provide a short script or the like that creates one. Are you sure that new servers are not starting up between when you issue the killall and look for new processes? Try taking inetd down before issuing the killall. You do mention 30 seconds - that's how long CVS waits for locks by default, but I don't think this should be a problem. I think SIGTERM should wake your processes from their sleep to exit. Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQFAbhvkLD1OTBfyMaQRAqVlAJ4zzFadYy8Kr7T3eJc2a0KyvYmJvACcDDUk I8UscY0Rds8wVQBiyCBFXFI= =j/pW -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvs as a heartbeat client (questions)
[EMAIL PROTECTED] wrote: Todd Denniston writes: 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. Todd, would an empty CVSROOT/writers file work for you? It won't completely block access to the repository, but it will prevent anyone checking anything in while the file exists. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs as a heartbeat client (questions)
Jim.Hyslop wrote: [EMAIL PROTECTED] wrote: Todd Denniston writes: 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. Todd, would an empty CVSROOT/writers file work for you? It won't completely block access to the repository, but it will prevent anyone checking anything in while the file exists. That unfortunately only works for :pserver:, which fortunately only three[1] of the repositories uses. Note: 19 repositories exist on the version control partition, and a couple of others temporarily exist in home directories (:ext: method). [1]and soon to be one...silly windows users. :) And as soon as I get the windows users on one of the rsh/ssh solutions there will be none. -- 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
Re: cvs as a heartbeat client (questions)
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 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs as a heartbeat client (questions)
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 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs as a heartbeat client (questions)
Todd Denniston wrote: 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? It's a simple matter to run a script from commitinfo and taginfo to check for the existence of a file and refuse to change the repository if the file exists. I believe those are the only operations you'd really have to be concerned about. =Bob= Bob Bowen [EMAIL PROTECTED] Process Engineering (952)876-4635 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
