CVS transient failure

CVS transient failure

[Zack Weinberg]

CVS spat out the following:

Cannot open /sourceware/cvs-tmp/#gcc.lastdir.12290, 
	stopped at /usr/sourceware/bin/commit_prep line 76, <ENTRIES> chunk 2.
cvs server: Pre-commit check failed
Cannot open /sourceware/cvs-tmp/#gcc.lastdir.12290, 
	stopped at /usr/sourceware/bin/commit_prep line 76, <ENTRIES> chunk 2.
cvs server: Pre-commit check failed

I tried it again and it worked; the disk is not full and the directory
is writable, so I don't know what went wrong.  I note there are an
awful lot of stale files in that directory.

It would be nice if that script read

    open(FILE, ">$filename") || die("Cannot open $filename: $!\n");

instead of

    open(FILE, ">$filename") || die("Cannot open $filename, stopped");

-- then you'd be told the actual error return from open(2) and have a
chance of figuring out what happened.

zw

Re: CVS transient failure

[Jason Molenda]

On Fri, Jun 02, 2000 at 06:58:08PM -0700, Zack Weinberg wrote:
> CVS spat out the following:
> 
> Cannot open /sourceware/cvs-tmp/#gcc.lastdir.12290, 
> 	stopped at /usr/sourceware/bin/commit_prep line 76, <ENTRIES> chunk 2.
> cvs server: Pre-commit check failed

Yeah, it exists:

-rw-r--r--   1 pme      libstdc+       36 May 24 11:35 #gcc.lastdir.12290

I've known about a (ahem) oversight in all the projects' commitinfo
setups for a while now, figuring it wouldn't cause problems.  

The commitinfo for every repo runs the commit_prep script for all
cvs commits ... but they don't run the log_accum script (which I
assume reliably cleans these things up) if the check-in is related
to the web pages - a separate script to update the web pages is
run for that.  So each web page checkin will leave behind a little
commit_prep doodie.

An entry like

htdocs   /bin/true

before the DEFAULT entry in repositories' CVSROOT/commitinfo file
would probably take care of the problem, but it'd have to be done
in every repository's setup.

The REAL problem here is that sourceware is too reliable and doesn't
reboot often enough.  We should add some bloated software with
memory leaks to cause the system to reboot every week or so.  ;-)


Jason (who should be ashamed :)

Re: CVS transient failure

[Frank Ch. Eigler]

Hi -

On Fri, Jun 02, 2000 at 06:58:08PM -0700, Zack Weinberg wrote:
> CVS spat out the following:
> Cannot open /sourceware/cvs-tmp/#gcc.lastdir.12290, 
> [...]
> 
> I tried it again and it worked; the disk is not full and the directory
> is writable, so I don't know what went wrong.  I note there are an
> awful lot of stale files in that directory.

That's exactly what it is: #gcc.lastdir.12290 already exists under a
different user.   It looks like the UNIX pid rolls over more frequently
than the junk #*.lastdir files are cleaned.

Good news: the probability of you hitting another stale file is pretty
low right now - ~1/300 (# stale files / sizeof pid space), and will rise
at this sort of rate (inverse exponential?) every month.

- FChE
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5OGlEVZbdDOm/ZT0RAc6lAJsE8x4DlLhA1CEJzHUHN9WNkPhP+gCeOx6p
/+AnoUYrhByBPK0BO0gpy84=
=lKoS
-----END PGP SIGNATURE-----

Re: CVS transient failure

[Jim Kingdon]

> It would be nice if that script read
>     open(FILE, ">$filename") || die("Cannot open $filename: $!\n");

Done (but untested).  If I broke something, I'm sure someone will let
me know :-).

Re: CVS transient failure

[Frank Ch. Eigler]

Hi -

On Fri, Jun 02, 2000 at 06:58:08PM -0700, Zack Weinberg wrote:
> CVS spat out the following:
> Cannot open /sourceware/cvs-tmp/#gcc.lastdir.12290, 
> [...]
> 
> I tried it again and it worked; the disk is not full and the directory
> is writable, so I don't know what went wrong.  I note there are an
> awful lot of stale files in that directory.

That's exactly what it is: #gcc.lastdir.12290 already exists under a
different user.   It looks like the UNIX pid rolls over more frequently
than the junk #*.lastdir files are cleaned.

Good news: the probability of you hitting another stale file is pretty
low right now - ~1/300 (# stale files / sizeof pid space), and will rise
at this sort of rate (inverse exponential?) every month.

- FChE
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5OGlEVZbdDOm/ZT0RAc6lAJsE8x4DlLhA1CEJzHUHN9WNkPhP+gCeOx6p
/+AnoUYrhByBPK0BO0gpy84=
=lKoS
-----END PGP SIGNATURE-----

Re: CVS transient failure

[Jason Molenda]

On Fri, Jun 02, 2000 at 06:58:08PM -0700, Zack Weinberg wrote:
> CVS spat out the following:
> 
> Cannot open /sourceware/cvs-tmp/#gcc.lastdir.12290, 
> 	stopped at /usr/sourceware/bin/commit_prep line 76, <ENTRIES> chunk 2.
> cvs server: Pre-commit check failed

Yeah, it exists:

-rw-r--r--   1 pme      libstdc+       36 May 24 11:35 #gcc.lastdir.12290

I've known about a (ahem) oversight in all the projects' commitinfo
setups for a while now, figuring it wouldn't cause problems.  

The commitinfo for every repo runs the commit_prep script for all
cvs commits ... but they don't run the log_accum script (which I
assume reliably cleans these things up) if the check-in is related
to the web pages - a separate script to update the web pages is
run for that.  So each web page checkin will leave behind a little
commit_prep doodie.

An entry like

htdocs   /bin/true

before the DEFAULT entry in repositories' CVSROOT/commitinfo file
would probably take care of the problem, but it'd have to be done
in every repository's setup.

The REAL problem here is that sourceware is too reliable and doesn't
reboot often enough.  We should add some bloated software with
memory leaks to cause the system to reboot every week or so.  ;-)


Jason (who should be ashamed :)

Re: CVS transient failure

[Jim Kingdon]

> It would be nice if that script read
>     open(FILE, ">$filename") || die("Cannot open $filename: $!\n");

Done (but untested).  If I broke something, I'm sure someone will let
me know :-).

CVS transient failure

[Zack Weinberg]

CVS spat out the following:

Cannot open /sourceware/cvs-tmp/#gcc.lastdir.12290, 
	stopped at /usr/sourceware/bin/commit_prep line 76, <ENTRIES> chunk 2.
cvs server: Pre-commit check failed
Cannot open /sourceware/cvs-tmp/#gcc.lastdir.12290, 
	stopped at /usr/sourceware/bin/commit_prep line 76, <ENTRIES> chunk 2.
cvs server: Pre-commit check failed

I tried it again and it worked; the disk is not full and the directory
is writable, so I don't know what went wrong.  I note there are an
awful lot of stale files in that directory.

It would be nice if that script read

    open(FILE, ">$filename") || die("Cannot open $filename: $!\n");

instead of

    open(FILE, ">$filename") || die("Cannot open $filename, stopped");

-- then you'd be told the actual error return from open(2) and have a
chance of figuring out what happened.

zw