0

Running Version 6.1.31 (DB 630, Build 57).

For the past few days, I'm continually getting

FogBugz maintenance discovered an expired lock - Delete 08/11/2011 19:01:33 PDT: An expired lock was broken by the FogBugz maintenance service. If this error persists, it may mean that the FogBugz heartbeat is failing.

The FogBugz Maintenance Service is not running. - Delete 08/11/2011 19:22:16 PDT: The last time the FogBugz Maintenance Service ran successfully was 08/11/2011 18:36:04 PDT. Please check your site configuration and make sure that the 'Maintenance URL' is pointing to the correct address.

The URL is correct, and the daemon should be running:

% ps -ax | grep ogb 123 ?? 0:06.42 mono /Library/WebServer/fogbugz/Accessories/SearchTool.exe -server /Library/WebServer/fogbugz/Accessories/search.socket 296 ttys000 0:02.01 /opt/local/bin/php -d max_execution_time=0 -d allow_call_time_pass_reference=Yes ./fogbugzmaintd.php 1465 ttys001 0:00.00 grep ogb

Things seem to be working (I'm getting and sending email from customers), but this is bothersome.

Indexing may be at fault, as searching for some things is failing.

I ran all the diagnostics and they passed.

flag

1 Answer

1

You should probably contact FogBugz directly by phone or e-mail for support here. I ran into a similar problem, and they were able to help me out in short order.

You can speed up troubleshooting by including the following information in an e-mail to them (along with versions of FogBugz, operating system, and underlying database). This is taken from an e-mail I received from Fog Creek Customer Service when I reported the problem:

  • From a MySQL prompt, run the commands CHECK TABLE FBLock, and CHECK TABLE FragmentCache, and send the results
  • From a MySQL prompt, run the command SHOW PROCESSLIST; and send me results
  • Enable slow query logging (as described in http://dev.mysql.com/doc/refman/5.1/en/slow-query-log.html), and send the corresponding log file.
  • Send your my.ini file

Note that it is probably not a good idea to attempt to interpret the results of these diagnostic steps without Fog Creek's help!

link|flag
They thought it might be overly large text being indexed mysql> SELECT ixBug, ixBugEvent, length(s) from BugEvent order by length(s) desc limit 20; shows this, and then I did e.g. update BugEvent set s="{removed >20 megabytes}" where ixBugEvent = 38913; to clear the big ones (which had large attachments). The largest ones were actually unviewable in a browser anyway. (As it happens, I have access to the attachments via the Gmail account.) I had to reboot and break the lock, but this may resolve things (still rebuilding the index so I don't know for sure). – David Dunham Dec 7 at 6:41
1 
sigh I keep forgetting you can't have useful formatting in a comment, like blank lines. – David Dunham Dec 7 at 6:42

Your Answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.