Bugzilla crashes when the database is gone, even when shutdownhtml is set

RESOLVED FIXED in Bugzilla 4.0



8 years ago
8 years ago


(Reporter: justdave, Assigned: LpSolit)



Bugzilla 4.0
Bug Flags:
approval +
approval4.0 +
blocking4.0.1 +



(1 attachment)

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.
Summary: Bugzilla crashes when the databases is gone, even when shutdownhtml is set → Bugzilla crashes when the database is gone, even when shutdownhtml is set
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)

Comment 2

8 years ago
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?
Keywords: regression
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] \nCan't connect to the database.\nError: Access denied for user 'bugstage02a'@'' (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/

Comment 5

8 years ago
WFM with 3.2, 3.4 and 3.6. Broken in 4.0 and 4.1, so this is really a regression.
Flags: blocking4.0.1+
Target Milestone: --- → Bugzilla 4.0

Comment 6

8 years ago
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.
Depends on: 428313

Comment 7

8 years ago
Created attachment 527442 [details] [diff] [review]
patch, v1

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.
Assignee: administration → LpSolit
Attachment #527442 - Flags: review?(justdave)
(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).
Attachment #527442 - Flags: review?(justdave) → review+


8 years ago
Flags: approval4.0+
Flags: approval+
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?

Comment 11

8 years ago
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.
Last Resolved: 8 years ago
Resolution: --- → FIXED
Could use a code comment referring to this bug imho...

Comment 13

8 years ago
(In reply to comment #12)
> Could use a code comment referring to this bug imho...

I already did, on checkin.
Haha, cool :D
You need to log in before you can comment on or make changes to this bug.