Re: waiting for user's lock

[Courier]

Mark,

Thank you for your clarified and comments. Yes, cvs the lock file is clear
up after some seconds. I don't know how long. Maybe 10s or maybe 30s, but
my trouble is: the old CVS server from Redhat7.1 with cvs version:
cvs-1.11-3 came with Redhat does not cause this lock files problems.
Meaning that I do have about 40 developers and 120 Engineers are doing
builds, updates, checkin, checkout, but I have not heard complaining for
last 4 years about cvs lock. So now, I just migrated to newer Hardware
with faster CPU and Disk drive and then cvs lock just pop up. The only
thing that trouble me is: to find out does this cause because a newer cvs
version cvs-1.11.2-13 has been changed some thing from the last
cvs-1.11-3.

I will send out the summary if we find the solution for this. If not I
will wait for a newer cvs release.

Thank you for your time Mark.

C-


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Courier <address@hidden> writes:
>
>> I need some help on cvs acting up on my cvs server. Here is what
>> happening:
>>
>> My users are just doing cvs diff or cvs log or cvs update, then they got
>> back cvs error: waiting for builder's lock and cvs server tell exactly
>> where is cvs PATH file that cause problems. The file name like:
>> #cvs.wfl.stein.29903, stein is cvs server name, 29903 is the process id.
>>
>> One of my developer did ps -ef on cvs server and found this:
>>
>> #ps -ef | grep cvs
>> 29903 ?        D      3:33 cvs -f --allow-root=/cvs/cvsroot/Repository
>> pserver
>>
>> So we are looking into D on ps and thinking that may be I/O problems?
>> or even network cause cvs system slow down?
>
> A wfl lock is a write lock such as is used when a user is committing a
> change to a file or files in a particular directory of the repository.
> It is temporary and is released when the operation has completed. As
> long as a process matching the pid on the lock file is present, you are
> probably okay.
>
>> But what I need from you is: does cvs cause problem or some thing else?
>
> Read http://www.cvshome.org/docs/manual/current/cvs_10.html#SEC88
>
>> My cvs server is Redhat9.0 with cvs version from redhat: cvs-1.11.2-13.
>
> This is valuable. Thank you for including it.
>
> Your users doing read-only operations like 'cvs diff' may find that
> using 'cvs -n diff' will have better performance for them.
>
> You may find that your users are taking a long time to manually write
> the log messages when they do a commit. Suggesting to them that they
> write their log message before issuing the cvs commit command and then
> pasting the log message into the cvs template or bypassing the template
> using the
>
>     cvs commit -F logmsg
>
> form of the cvs commit command may let you see less time being spent in a
> cvs lock state.
>
>> Also all other build servers we have is P4 1.2 GHZ, but cvs server is :
>> dual Xeon P4. Not sure that help, but i throw it out there just in case
>> some one may ask.
>>
>> I did search older archive and found some responded back from Larry
>> about
>> LockDir may be some where else. We do not have LockDir. Cvs server does
>> lock by itself.
>>
>> Can some one help?
>
> The problem of write locks gets easier in the development branch of cvs
> with promotable locks. You may wish to wait for cvs-1.12.6 as I believe
> that there is a case where a core dump occurs with cvs 1.12.5 right now
> (it is fixed in the CVS TRUNK).
>
>       Good luck,
>       -- Mark