info-cvs
[Top][All Lists]
Advanced

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

Re: Have I got a corrupt repository?


From: Mark D. Baushke
Subject: Re: Have I got a corrupt repository?
Date: Tue, 13 Jan 2004 07:03:23 -0800

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andy Jones <address@hidden> writes:

> [Red Hat 7.1, CVS 1.11.10]
> 
> I've been trying to check in a *big* change over pserver and getting
> some nasty crashes from CVS (which unfortunately I did not take a note
> of - "System exit 11"?). Eventually I discovered that this particular
> client machine had an older version of CVS on it - 1.10.8 - and put it
> down to that.

An exit 11 should be EAGAIN (check your /usr/include/asm/errno.h). This
should be telling cvs that there is a transient error that needs to be
retried. Without a better indication of what was happening, it is hard
to tell you any more information.

> So I FTP'd the big change across to the server machine and tried
> again, but I'm seeing some Weird Stuff:
> 
> * I have some files which cvs status shows as "locally modified" but
> cvs -n commit does not list. If I do cvs commit without the -n,
> though, that's okay.

A file is considered "locally modified" if it has a timestamp different
than the value in the CVS/Entries file. A cvs commit will ignore files
that compare the same as the original and update the CVS/Entries file.

> * CVS keeps telling me that it's waiting for a lock to be freed.
> No-one else is using CVS, though.  As per the manual, I'm deleting the
> lock files.  But I've never had this problem before.

If cvs crashed once previously, it is possible that it left stale locks
in the repository. There are three kinds of locks that might be visible
in the directory.

  a) #cvs.lock  - a directory (used when creating #cvs.[rw]fl.* locks)
  b) #cvs.rfl.*.<pid> or #cvs.wfl.*.<pid>
  c) ,<file>,

If you have just a #a lock in the directory, then you should be able
to safely remove that directory. It is created for a very brief time
to get an exclusive lock so that it believes it is safe to create 
either a read or write file lock file.

If you have a #b lock, then check to see if the <pid> is a valid process
id on your server (ps -p <pid>). If it is a valid pid and it is a 'cvs'
process, then the lock is still valid. If it is not a valid pid, then
you should be able to safely remove it.

If you have a #c lock, then RCS died when it was trying to update a
<file>,v which it does by writing the new file into ,<file>, and then
renaming as <file>,v ... you should be very careful and compare the
,<file>, and <file>,v files to see how they compare. However, it
is probably okay to just move the ,<file>, to some other filesystem
directory

> Do I have a corrupt repository?

We don't know that yet, all you have complained about is locks.

> If so, can it be repaired?  

Possibly.

> I can restore a backup of the repository if necessary, but if there's
> an easier way...

Andy Jones <address@hidden> writes:

> When I commit I'm also seeing:
> 
> Rlog: RCS/<somefile>: No such file or directory

cvs does not ever produce an 'Rlog: RCS/<somefile>' message.
Unless you provide actual cvs messages, your panic may only
increase as folks ignore the e-mail as being unrelated to cvs.

Andy Jones <address@hidden> writes:

> I've now restored to an earlier version of my repository.

Well, that was a short wait after sending e-mail asking for help, but
I do understand you must be under time pressure.

> But when I'm committing I still see
> 
> rlog: RCS/<somefile>: No such file or directory
> 
> 
> And my "big commit" eventually falls over with "Segmentation fault
> (core dumped)".
> 
> Any ideas?

None at all at this point.

Andy Jones <address@hidden> writes:

> Okay, now I'm starting to panic.
> 
> 
> [1005]~/tapestry/cl: cvs commit -F ~/mess |less
> cvs commit: Examining . à""@à""@ð""@ð""@ø""@ø""@' check failed for `8õ
> cvs commit: Examining calcs
> cvs [commit aborted]: correct above errors first!

A cvs commit will only print 

    Up-to-date check failed for `<filename>'

where <filename> is the name of a <filename>,v that corresponds to the a
file that exists in the repository.

The other odd characters are not normally part of cvs output.

> [1006]~/tapestry/cl: cvs -n update
> cvs update: Updating .
> U ItemList_ie.htm à""@à""@ð""@ð""@ø""@ø""@ is not (any longer)
> pertinent
> cvs update: Updating calcs

cvs will normally print

    warning: <filename> is not (any longer) pertinent

where <filename> is the name of a <filename>,v that corresponds to the a
file that exists in the repository.

I agree that something odd is happening to you.

You should check that you have enough swap space on your system
so that you can have a process that is ~2.6 times the size of your
largest file being committed. Your /tmp filesystem also needs to
hold a copy of the tree in /tmp/cvs-serv* that is big enough to hold
multiple checked out trees of your repository at the same time.

If you have any core dumps, feel free to use gdb to get a backtrace of
where things went wrong and send it here to address@hidden You
probably want to send the information in a way that is NOT going to be
mangled with word-wraps by your e-mail client. Possibly, putting the log
file up on a web site and sending a URL of it to this list would make
more sense.

        Good luck,
        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFABAi73x41pRYZE/gRAnfQAJwNEDjA7RC0szAwQQn8tVEb2j3PRgCgibxt
WIr9V70Gp1HbO7o+YY4cfu0=
=oNtd
-----END PGP SIGNATURE-----




reply via email to

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