[Top][All Lists]

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

Re: CVS Lock Errors

From: S I
Subject: Re: CVS Lock Errors
Date: Thu, 16 Jun 2005 22:56:43 -0700

I'm ok now. Oddly I didn't find any cvs processes running on the unix server. So I cut & paste the error msgs into google and found out cvs.locks were created by the user, inadvertently, and we had to delete them manually. Thank you very much for the info and your time. :)

----Original Message Follows----
From: Todd Denniston <address@hidden>
To: S I <address@hidden>
CC: address@hidden
Subject: Re: CVS Lock Errors
Date: Thu, 16 Jun 2005 19:13:39 -0500
MIME-Version: 1.0
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 17:16:50 -0700 Received: from (address@hidden []) by with ESMTP id TAA26924; Thu, 16 Jun 2005 19:14:42 -0500
X-Message-Info: JGTYoYF78jEHjJx36Oi8+Z3TmmkSEdPtfpLB7P/ybN8=
Organization: Code 6067, NSWC Crane
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.25glock1 i686)
X-Accept-Language: en
References: <address@hidden>
Return-Path: address@hidden
X-OriginalArrivalTime: 17 Jun 2005 00:16:51.0102 (UTC) FILETIME=[DBC8ABE0:01C572D1]

S I wrote:
> Hi
> I have a 2nd question:
> A user using Tortoise window's client using :pserver to the linux box,
> executed the commad searching for tags. Not a specific tag but all tags in > the repository. The command's been running for about 15 hours now, locking
> cvs, and not allowing anyone else to tag.  We can update, commit, etc but
> not tag. And I do need to tag my build today.
> When I try to tag, I get the error msg that so & so user has it locked. When
> I do -cvs admin -U, the server says waiting for the user's lock, etc.
> On the linux server side, I thought it was a ps process I could kill...but

If it is a process that is still running,  you should be able to find the
process with
`ps options |grep cvs` where options are either "aux" or "ef".

> How can I kill this annoying process? I told him to delete all his working
> folders, reboot, and check out fresh and anew again.

If he has done all the those things, which should be unnecessary, and the ps
netted nothing ... some how cvs (on the server) was terminated while he was
doing his tag search and was not given a chance to clean up after itself.

> Any suggestions?
with all the above going on I would:
1) configure inetd or xinetd to not run any more cvs processes while I
figure out what is going on. (and restart [x]inetd)
2) stop any currently running cvs instances (under linux on the server)
        `killall -SIGTERM cvs;echo "nice kill done"; \
        sleep 60; killall -9 cvs; echo "lets se-em survive that"`
        #if you get any output before the "nice kill done" echo,
        #there were no cvs's running.
3) make a backup of the repository.
4) run Donald Sharp's check_cvs script to see what if anything is amiss with
the repository
5) take note of and delete any locks check_cvs finds.
6) decide if you want to fix anything else check_cvs finds.
7) take some guesses as to how it got into this state
(this seems like a very weird state to me, it would probably be good to let
the mailing list know what version of cvs you are running on the server and
Tortoise. have you ever had this search for all tags action work in the
8) put the system back on line for cvs work. reconfigure [x]inetd to run cvs
pserver and restart [x]inetd.

9) you might want to check and make sure everyone is accessing the repo
through pserver or ext (to the same server machine) and that no one is
accessing it using a filesystem method.

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]