If shutdownhtml is set, that should be caught first *before* any attempt is made to connect to the database (except on the pages which are exempt). Otherwise, it's pointless to set shutdownhtml when you'll be doing database maintenance.

I searched and searched for this, it's been known about for so long, I was shocked to see there wasn't already a bug for it (or I'm just blind and not searching for it right)

Unless my patch in bug 398075 was incomplete (which shouldn't be, AFAIK), this is a regression. justdave: could you paste the error you get?

Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, root@localhost and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. Apache/2.2.3 (Red Hat) Server at bugzilla-stage-tip.mozilla.org Port 443

[Tue Apr 19 11:56:25 2011] [error] [client 10.2.74.5] \nCan't connect to the database.\nError: Access denied for user 'bugstage02a'@'10.2.74.72' (using password: YES)\n Is your database installed and up and running?\n Do you have the correct username and password selected in localconfig?\n\n, referer: https://bugzilla-stage-tip.mozilla.org/

WFM with 3.2, 3.4 and 3.6. Broken in 4.0 and 4.1, so this is really a regression.

This is a regression due to bug 428313. When the DB is not accessible, [% SET css_sets = css_files(style_urls, yui, yui_css) %] in global/header.html.tmpl calls Bugzilla::Template::css_files() which calls Bugzilla::Template::_css_link_set() which calls Bugzilla->user->settings, which is not available as ->settings gets the user pref values from the DB.

In Bugzilla.pm, we explicity set $user->{settings} = {} when shutdownhtml is true. So all we have to do is to make sure the hash is not empty before looking for its values. Note that if you try to access editparams.cgi directly, you still get a SQL crash. But this is not a regression as it has always been so. The reason is that editparams.cgi is in the SHUTDOWNHTML_EXEMPT list, and so is not affected by the code I'm talking above. It would still be good to fix it, but it requires some refactoring in Bugzilla.pm which I don't want to do here as it may have unexpected side-effects.

(In reply to comment #7) > Note that if you try to access editparams.cgi directly, you still get a SQL > crash. Yeah, fine with me, only admins should be hitting that page anyway, and they'd probably know the DB was down.

Comment on attachment 527442 [details] [diff] [review] patch, v1 Looks good. Testing on bugzilla-stage-tip (4.0) and works there (no crash when database is gone and shutdownhtml is up).

Cool. Thanks for tracking this down and fixing it, LpSolit. :-) On checkin, could you add a comment explaining why the code does that, so somebody doesn't revert it later?

Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/trunk/ modified Bugzilla/Template.pm Committed revision 7779. Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/4.0/ modified Bugzilla/Template.pm Committed revision 7571.

Could use a code comment referring to this bug imho...

(In reply to comment #12) > Could use a code comment referring to this bug imho... I already did, on checkin.

Haha, cool :D