256019 - Lost power to server while 'shutdownhtml' was active -- had a tough time re-enabling buzilla since I lost my connection to the server

Status: RESOLVED FIXED

(Bugzilla :: Documentation, defect)

Description

[Joe Bishop]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705)
Build Identifier: 

IMHO a little note in the docs to describe what to do in the event of power 
loss when 'shutdownhtml' is enabled could have saved me some time getting the 
server sorted out and back online. Adding the following to section 3.1 Bugzilla 
Configuration #6 would be helpful :-)

6. shutdownhtml: If you need to shut down Buzilla blah blah blah...
In the event that you loose your connection to Bugzilla, you can manually edit 
$BUGZILLA_HOME/data/params and remove that string associated 
with 'shutdownhtml' Otherwise Bugzilla will never get out of this state.

Or another possible solution is to have the 'checksetup.pl' script detect 
that 'shutdownhtml' has been activated and if it should be removed or 
whatever...



Reproducible: Always
Steps to Reproduce:
1. Config a bugzilla server
2. activate the 'shutdownhtml' message
3. reboot machine (or terminate connection to server and flush any cache 
associated with connection)

Comment 1

[Joel Peshkin]

yeah, this belongs in the docs

Comment 2

[Shane H. W. Travis]

Attachment: Doc changes for 2.18 and tip

As usual, I cleaned up more than just what was directly called for in the bug.
* Added requested note to 'shutdownhtml'
* Removed all tabs from id="parameters" section
* Re-indented/re-wrapped id="parameters" section (no textual changes
    except where noted)
* Reworded the 'supportwatchers' section to eliminate redundancy and make the
    main point more clear.

Comment 3

[Shane H. W. Travis]

Attachment: Doc changes for 2.16

Same changes as for 2.18+tip, plus some back-filling of changes to the 2.18
docs that looked like there was no reason to keep them out of 2.16. These
include:
* section on row-locking in newer MySQL versions in the "shadowdb" param
* added comment 'on reasonably old hardware' in "shadowdb" param
* section on the (mis-named) "movebugs" parameter 

Apart from things that are new to 2.18 (such as noresolveonopenblockers) and
changed between 2.16 and 2.18 (makeproductgroups/usebuggroups) these two
sections should now be identical.

Comment 4

[Jacob Steenhagen]

I really thought it was still possible to access the editparams.cgi script from
a webbrowser even if shutdownhtml was active. I really seem to remember doing
something along those lines at some point in the past.

Comment 5

[Jacob Steenhagen]

Found it: Bug 95082 comment 6. Has something changes since then? Or wasn't that
the problem you were seeing?

As an aside, that doesn't necessarily mean the patches here are not valid, I'm
just trying to make sure the facts are right :).

Comment 6

[Shane H. W. Travis]

The information in this patch is factually correct; I checked it myself before 
writing it. (Didn't know I needed to put that in the patch notes, or explain 
that to the reviewer...)

When 'shutdownhtml' has something in it, *you cannot log in*. As long as you 
are still logged in -- and still the admin -- you can get back to 
editparams.cgi to change the shutdown.html. If you lose your login for any 
reason, though, you cannot log back in which means you can't tell it you're the 
admin which means you can't get to editparams.cgi. This is what happened to the 
original poster, which is what I'm documenting how to get around.


Factually, it's correct. I see some XML errors, though (didn't run this through 
onsgmls, apparently) so I'm making new patches.

Comment 7

[Shane H. W. Travis]

Attachment: Doc changes for 2.16, try #2

Comment 8

[Shane H. W. Travis]

Comment on attachment 167041 [details] [diff] [review]
Doc changes for 2.18 and tip

Only SGML error in this one is that <finenme> should be <filename>; if someone
can fix that up on checkin, I'd appreciate it. (Of course, if it gets an r- and
needs another patch, I'll fix it myself.)

Comment 9

[Jacob Steenhagen]

My wording was unclear, but when I said "make sure the facts are right," I meant
in my own head. I remember doing the patch where Bugzilla's support of
shutdownhtml became more complete and remember that being able to login to
remove shutdownhtml was a very important aspect of it. I'm curious where this
changed.

As I said in comment 5, this doesn't effect in any way the validity of these
patches. I just didn't have time to review them at that point. I still don't
think that the validity of these patches is in question, but I do think that a
bug should be filed about this issue requesting that the ability to login on the
editparams page be restored.

Comment 10

[Jacob Steenhagen]

I was about to file the bug I mentioned in comment 9, but figured I'd better
test first. I used the following procedure on all three versions of Bugzilla
(2.16.7, 2.18rc3, tip):

1. Login as with my admin account.
2. Visit editparams.cgi and put something in shutdownhtml.
3. Visit one of the footer links to ensure Bugzilla is shutdown.
4. Removed the cookies from my browser related to Bugzilla (to simulate logout).
5. Visted editparams.cgi again. At this point, I was asked to login.
6. Logged in successfully.
7. Clicked the "Reset" button for shutdownhtml.
8. Verified that Bugzilla worked again by clicking on a footer link.

It is true that the "Log In" link in the footer doesn't work, but visiting
editparams.cgi directly allows one to log in even if Bugzilla is shutdown (for
this express purpose). We should certainly document that one should visit
editparams.cgi directly when shutdownhtml is active, but don't need to mention
manually editing data/params (which, IMHO, should never be necessary).

Comment 11

[Jacob Steenhagen]

Comment on attachment 167041 [details] [diff] [review]
Doc changes for 2.18 and tip

As mentioned in comment 10, one should visit editparams.cgi directly and not
edit data/params manually.

Comment 12

[Jacob Steenhagen]

Comment on attachment 168147 [details] [diff] [review]
Doc changes for 2.16, try #2

As mentioned in comment 10, one should visit editparams.cgi directly and not
edit data/params manually.

Comment 13

[Shane H. W. Travis]

> It is true that the "Log In" link in the footer doesn't work

Actually, the "Log Out" link in the footer doesn't work either; see bug 273767 
filed against this issue. (IMHO People should be able to log out even if 
Bugzilla is shut down.)


> but visiting 
> editparams.cgi directly allows one to log in even if Bugzilla is shutdown (for
> this express purpose). 

10-4. I'll change the patch to say to do it this way instead. (The other way 
*works*... but this is definitely more elegant. :)

Comment 14

[Shane H. W. Travis]

Attachment: Doc changes for 2.16, try #3

Relevant section re-written to incorporate new information.

Comment 15

[Shane H. W. Travis]

Attachment: Doc changes for 2.18 and tip, try #2

Comment 16

[Jacob Steenhagen]

Comment on attachment 168424 [details] [diff] [review]
Doc changes for 2.18 and tip, try #2

> +          <command>shadowdb</command>:

*nit* This param no longer exists in 2.18. I'm pretty sure we have text
elsewhere in the guide that mentions using replication instead, so this text
should be able to be pulled out.

*nit* These paramaters would really be better off as a <varlist/>, I think.

Neither one of these is worth withholding review for (this isn't a general
cleanup bug :), so I'll file another bug.

Comment 17

[Jacob Steenhagen]

Comment on attachment 168423 [details] [diff] [review]
Doc changes for 2.16, try #3

Looks good (same varlist nit, but same reasoning).

Comment 18

[Jacob Steenhagen]

I was about to file the bug about shadowdb when I realized that I was reading
the 2.16 version when I noticed it. The 2.18 version does say to use database
replication. So I withdraw my first nit entirely.

Bug 274173 filed to cover the <varlist/> nit.

Patches check in to: tip, 2.18, 2.16.