Closed Bug 62381 Opened 25 years ago Closed 25 years ago

cvs-mirror/stale lock problem

Categories

(mozilla.org Graveyard :: Server Operations, task, P3)

Product:
mozilla.org Graveyard
Component:
Server Operations
Type:
task

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: sreid, Assigned: drew.streib)

Details

Can't CVS the lizard from cvs-mirror.mozilla.org. Looks like a stale lock. cvs server: [23:22:46] waiting for cvsuser's lock in /cvsroot/mozilla/xpfe/communicator/resources/locale [...] cvs server: [23:34:46] waiting for cvsuser's lock in /cvsroot/mozilla/xpfe/communicator/resources/locale That was from my second attempt. Stuck in the same place as my first attempt. I think the lock has been there for at least half an hour.
I got this once, but I'm also getting "No space on device" errors before this, sometimes. This isn't on my machine - its referring to cvs-mirror.
cvs-mirror is handled by Sourceforge/VA Linux
Assignee: rko → dtype
Does that mean this is the wrong place to report the problem? If so, what is the correct way? I am seeing exactly the same problems reported above. Most recently 12-9 7 AM EST we seem to be back to "no space left on device".
yes, this is the correct place. that comment meant that risto was reassigning the bug to a sourceforge person.
just phoned the valinux IS number and in the process of being forwarded somewhere, got hung up on. Also sent mail to sourceforge people about the problem last night. Not sure if anyone is around over the weekend though.
resummarizing
Summary: cvs lock in /cvsroot/mozilla/xpfe/communicator/resources/locale → cvs-mirror/stale lock problem
Its probably /tmp being filled up, especially if its on the same partition as the log files. Can anyone at netscape/mozilla ssh to the box?
Apparently noone at Mozilla.org has access to the box, which is why this hasn't been fixed.
I have the access but it's not really my job to support this server... Anyway, /tmp had run of inodes. I'm cleaning something and that hppefully will make it better.
I recreated /tmp filesystem and doubled number of inodes from 256k to about 524k (I think that's max with current size of disk and minimum blocksize).
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
I'm watching this now as well, and risto's inode solution appears to have worked. This is all working for me now, but I'll keep monitoring. Sorry it took so long to get to this. I was in New Orleans for a few days at USENIX/LISA and had trouble getting connected much of the time.
Verified.
Status: RESOLVED → VERIFIED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.