Thanks to everyone who pointed this out ... we worked with the bugzilla developers to help track down the source of this bug and they now have acknowledged it:

https://bugzilla.mozilla.org/show_bug.cgi?id=441592

I imagine there will be an upstream fix at some point and we will update the JumpBox as soon as we can. In the meantime, the 1.1.0 Bugzilla JumpBox has the workaround I mentioned above in place which should help some people out. I will take that out once the real upstream resolution is in available.

Those of you with older versions with this problem ... you can play with the wait_timeout if you want, it appears to be an OK work around.

Austin

Ok, we have pursued a number of fixes to this over the last few weeks, none of which have worked to our satisfaction. I have a possible fix at the database server level that appears to work well for me but I am uncertain how well it will work through long term usage. Is there anyone out there who is experiencing this bug who is interested in trying something out for me for a week or so? If so, here is a description of the problem as I understand it and the instructions of what to do to attempt to fix it and how to revert it if the fix proves to be problematic.

The problem

First off, this bug is, as the error message indicates a result of the database running out of connections. This does not appear to be a mismatch in apache workers and mysql max connection settings or anything like that, nor is it necessarily a bug in mod_perl (not completely ruled out, but the newer versions exhibit the same problem). This appears to be a case of bugzilla not releasing database connections correctly. So the solution I want to try is to timeout the sleeping database connections that are left by bugzilla (as seen by issuing sudo mysqladmin --defaults-file=/etc/mysql/debian.cnf processlist on the jumpbox). The default timeout is 8 hours, which is proving to be insufficient.

The workaround

So, how can you try the fix? First off, don't try this unless you are willing to be vigilant and monitor the results or at least be within earshot of your angry users. All we are going to do is change the timeout from 8 hours to something more suitable for this app. So edit your my.conf as root as follows:

sudo nano /etc/mysql/my.cnf

Now place a timeout of, say 300 seconds in the [mysqld] section. So right after the [mysqld] in that file:

[mysqld]
wait_timeout    = 300

now restart apache:

sudo /etc/init.d/mysql restart

Now all you have to do is use bugzilla for a while. If you start having other problems you can revert the change by deleting or commenting out the line added above and restarting mysql again. Report back here and let me know how it goes. We will continue testing this internally and perhaps release an update with this change in place.

Austin

We are experiencing this at an almost daily rate at the moment.

Thanks for the quick reply.

I have 3 users setup which access the box installed on a desktop under a VM. Not heavy usage.

Also, I'm using Mylyn under eclipse which polls the box for tasks on a schedule (1 user). I was wondering if Mylyn's connections when it updates are being left open which eventualy hit a limit?

VM: microsoft running under windows xp 64 bit
Eclipse: IBM Rational Application Developer v7.0
Mylyn: 2.0
ie:6

Starts doing this after some usage. If left alone will again accept new connections. Rebooting always clears the issue.

Thanks
rod

Hi

We will try to recreate this error internally. Can you provide any more details on what your usage is like to help us recreate this?

Austin