#417 ✓wontfix
Richard Toohey

If database down, Exponent 2.0.2 launches installer for upgrade

Reported by Richard Toohey | December 3rd, 2011 @ 08:17 AM | in 2.0.3 (closed)

Hi, guys.

(I need to double-check this behaviour, upgrading my dev. machine at the moment.)

2.02 installed, all going nicely. My page sitting in Firefox.

I upgrade MySQL 5.1.59 to 5.1.60 - as part of the upgrade, MySQL stops.

Idle curiosity - what happens to Exponent? Refresh my page - various messages about cannot connect, etc. as expected ... but ...

Exponent CMS
Simple Site Upgrade

Since your website has a configuration file already in place, we're going to perform a couple simple tasks to ensure you're up and running in no time.

Next, we'll Install Tables, and then run through any upgrade scripts needed to bring your code and database up to date.
Continue to Install Tables

What??? Not a good look, so I quickly started MySQL ...

But - Exponent still wants me to go through the installer - it has gone and created a NEW install/not_configured file, so from now on it will go round this loop.



 88         // check to see if we need to install or upgrade the system
 89         expVersion::checkVersion();


     48         /**
     49          * Routine to check for installation or upgrade
     50          */
     51         static function checkVersion() {
     52                 global $db;
     54                 // we're not up and running yet, so fix that first
     55                 if (@file_exists(BASE.'install/not_configured') || !(@file_exists(BASE.'conf/config.php'))) {
     56                         self::launchInstaller();
     57                 }

First time through (when MySQL down) - neither of those conditions true, so launcher not installed here ...

     59                 // version checking routine, check database version against software version
     60                 $dbversion = $db->selectObject('version',1);
     61                 if (empty($dbversion)) {
     62                         $dbversion->major = 0;
     63                         $dbversion->minor = 0;
     64                         $dbversion->revision = 0;
     65                         $dbversion->type = '';
     66                         $dbversion->iteration = '';
     67                 }

MySQL down - so I'm guessing $dbversion will be empty - so we say version major is 0.

     68                 if ($dbversion->major < EXPONENT_VERSION_MAJOR) {
     69                         self::launchInstaller();

0 is < 2, so let's launch the installer ...

And what does the installer do?

     90         static function launchInstaller() {
     91                 // we'll need the not_configured file
     92                 if (!@file_exists(BASE.'install/not_configured')) {
     93                         $nc_file = fopen(BASE.'install/not_configured', "w");
     94                         fclose($nc_file);

So, even when I restart MySQL - the launcher has created install/not_configured.

So now I'm stuck in the run install loop. Next page refresh hits line 54 - which now finds the not_configured file.

So imagine you are upgrading MySQL on a server (or MySQL is down for whatever other reason, or runs out of connections, etc.) A web visitor (human or spider) hits the page when MySQL stopping/down. Can't do version check, so it creates the not_configured file. Your next visitor after MySQL is restarted is going to be in the installer.

(Don't have a fix for this at present, as above - I'm upgrading my development machine.)

Apologies in advance if a red herring - I definitely DID see something odd, and what I saw definitely seems possible from the code - once I get this machine upgraded I'll confirm.


Comments and changes to this ticket

  • dleffler

    dleffler December 3rd, 2011 @ 11:55 AM

    • Milestone set to 2.0.3
    • State changed from “new” to “wontfix”
    • Tag set to installer
    • Assigned user set to “dleffler”
    • Milestone order changed from “127” to “0”

    This is the designed/desired/expected 'self-healing' behavior. The upgrade routine is non-destructive. Exponent can NOT operate without a functional database! If it can't connect or find a few basic tables, it assumes the database has been deleted/moved and enters the routine to install or upgrade. If the config.php file exists, it first tries the upgrade routine (which only updates the database tables to an expected structure) and if a few basic tables don't exists, it falls back to a full install routine.

    IF YOU ARE UPGRADING YOUR SERVER, you probably want to/should place the site in 'Maintenance Mode"

    FWIW, in 2.0.3 to be released soon, those initial database (error/warning) messages have been circumvented.

  • dleffler

    dleffler December 3rd, 2011 @ 12:17 PM

    FWIW, We might also note that due to the nature of a php server-side language, functions can't just run until completion as the internet/network is designed to time-out server/internet/network connections (unless you run php scripts from the command line)...so multiple steps become multiple pages to keep the whole site from breaking with a server timeout error.

  • Richard Toohey

    Richard Toohey December 3rd, 2011 @ 08:43 PM

    HHhhhmmm, I see what you are saying, but don't agree.

    It doesn't seem to be a good situation to say "I cannot connect, therefore assume I have to install and create a file on the server" - especially when you present that to Joe Public web client.

    I was looking for a more graceful handling of the situation when checking the version string - don't assume because you can't connect that an upgrade is required.

    If I've got 50 Exponent sites, I have to put all 50 in maintenance mode to gracefully cope with the 10 second downtime while MySQL stops & the new binary starts?

    Remember that there might be a transient condition - for some reason MySQL is briefly unavailable (it just happened to me during an upgrade.) You might not have time to put the site(s) into Maintenance mode. So, you are hosting your 75 Exponent sites on provider X's server - provider X has an issue with MySQL being down for 30 minutes. Provider X's tech guys fix the situation as quickly as they can - but you now have 75 sites all telling the end user that they need to install tables as part of an upgrade ... that really does not sound right.

    I'll see if I can offer some code to make things work better for me. (Shut up & hack.)

    Thanks for the prompt response.

  • dleffler

    dleffler December 3rd, 2011 @ 10:40 PM

    I'd say we're open to ideas on how to change this, but in regards to this ticket the system is working as expected...and this design provides a semi-intelligent method to install/upgrade/repair a site.

    The 'not_configured' file is written in response to a 'bad database situation'. It simply acts as a place holder so the upgrade/install process will run to completion without dumping out BEFORE an upgrade/reinstall is completed.

  • Richard Toohey

    Richard Toohey December 4th, 2011 @ 02:18 AM

    A little light-bulb is illuminating ... back to your earlier comment:

    "Exponent can NOT operate without a functional database! If it can't connect or find a few basic tables, it assumes the database has been deleted/moved and enters the routine to install or upgrade."

    To me, that absence of a database means a fatal condition - one that means we need to stop and say "something's wrong here" and give up at that point. It's not safe (in my opinion) to continue. (So sysadmin can scuttle off, find out what's happened to the database, fix it.)

    But to Exponent (as designed), the absence of a database means "assume that we need to upgrade/install, so ask the user(s) currently viewing the webpage what to do"

    I can see what you mean now (thanks for taking the time to spell it out), but I still think it's odd to present the next visitor of your website with a message that says "let's play with database tables." Personally I would prefer the next visitor (assuming MySQL/database down) to see a message along the lines of "Database down, come back soon" (or maybe the 2.0.3 changes you mentioned above will do something along those lines) and then the visitor after that (assuming MySQL/database back by then) to see the normal site. No web visitor gets to see that. Forcing the site(s) into an unavoidable upgrade routine because of a transient database issue just doesn't "feel" right to me.

    I'll still proceed to see what I can come back with, but I understand what you are saying - this is a conscious design choice in Exponent.


  • dleffler

    dleffler December 9th, 2011 @ 09:38 PM

    This has been moved to ticket #421

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Bug Tracker for Exponent CMS

Shared Ticket Bins

People watching this ticket


Referenced by