Re: Killed Gump, removed locks
On Wed, 22 Jun 2005, Adam R. B. Jack <[EMAIL PROTECTED]> wrote: > Did this stabilize since I set the number of background updaters to > 0? The previous situation looked OK for a few days as well, so it may be too early to judge. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Killed Gump, removed locks
Did this stabilize since I set the number of background updaters to 0? If so, we could think about trying 5 (which is what Brutus had). Or, ought we just leave well alone for now? regards Adam - Original Message - From: "Stefan Bodewig" <[EMAIL PROTECTED]> To: Sent: Monday, June 20, 2005 8:46 AM Subject: Re: Killed Gump, removed locks > On Mon, 20 Jun 2005, Adam R. B. Jack <[EMAIL PROTECTED]> wrote: > > > Sorry, can you be more explicit? What sort of locks? > > gump.lock was present, and belonged to the Gump instance from Sunday > noon. > > Inside of workspace/cvs there have been ten .lock files all dated > between 0 and 1am Sunday morning. > > Stefan > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Killed Gump, removed locks
- Original Message - From: "Stefan Bodewig" <[EMAIL PROTECTED]> To: Sent: Monday, June 20, 2005 8:46 AM Subject: Re: Killed Gump, removed locks > On Mon, 20 Jun 2005, Adam R. B. Jack <[EMAIL PROTECTED]> wrote: > > > Sorry, can you be more explicit? What sort of locks? > > gump.lock was present, and belonged to the Gump instance from Sunday > noon. Ok. Just for clarity, this lock file can exist (even if the process is dead) but unless it is POSIX locked it isn't a problem. If the process isn't dead, chances are it is lock. Still, this is likely a side-effect of the real problem, i.e. whatever is hanging Gump. > Inside of workspace/cvs there have been ten .lock files all dated > between 0 and 1am Sunday morning. I believe these locks are (as you say) a result of SVN failures (perhaps us killing it due to hang-up.) What we've experienced is that they cause a new "svn update" (should one occur, see gump.lock above) to fail stating we need to do an "svn cleanup". I'll code this one of these days, but it doesn't seem like it should be the cause but a symptom. So, we still need to track down the root cause of why VmGump is hanging. Hopefully setting the number of background threads to 0 will help. Anybody know of any log files/other on Linux that could tell us if a system resource had been exhausted? Could (say) file handles have been exhausted, or something else that SVN uses? regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Killed Gump, removed locks
On Mon, 20 Jun 2005, Adam R. B. Jack <[EMAIL PROTECTED]> wrote: > Sorry, can you be more explicit? What sort of locks? gump.lock was present, and belonged to the Gump instance from Sunday noon. Inside of workspace/cvs there have been ten .lock files all dated between 0 and 1am Sunday morning. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Killed Gump, removed locks
Sorry, can you be more explicit? What sort of locks? BTW: We can limit the number of background threads (to none, if needed) for updates by editing the workspace definition. regards Adam - Original Message - From: "Stefan Bodewig" <[EMAIL PROTECTED]> To: Sent: Monday, June 20, 2005 1:00 AM Subject: Killed Gump, removed locks > Hi all, > > logfiles are in ~gump/20050619. > > This time it looks as if the midnight run Sunday morning died during > updates or syncs and didn't clean up after itself. The noon run then > made it into the updates and starved because of the locks left over > from midnight. > > Stefan > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Killed Gump, removed locks
Hi all, logfiles are in ~gump/20050619. This time it looks as if the midnight run Sunday morning died during updates or syncs and didn't clean up after itself. The noon run then made it into the updates and starved because of the locks left over from midnight. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
