CiviCRM Community Forums (archive)

I just upgraded a 4.2.7 demo system to 4.3beta4. Environment is a fully-patched CentOS 6.4. system:
httpd-2.2.15-26.el6.centos.x86_64
mysql-5.1.67-1.el6_3.x86_64
php-5.3.3-22.el6.x86_64

Running the upgrade URL originally gave a blank page with the following error in /var/log/httpd/error_log:

[Sun Mar 24 10:45:54 2013] [error] [client 68.55.8.42] PHP Fatal error:  Call to undefined method CRM_Core_DAO::getGlobalSetting() in /var/www/html/drupal7/sites/all/modules/civicrm/CRM/Upgrade/Form.php on line 407

Which is the check for the MySQL thread_stack setting

    if (CRM_Core_DAO::getGlobalSetting('thread_stack', 0) < (1024*self::MINIMUM_THREAD_STACK)) {
      $error = ts('CiviCRM %1 requires MySQL thread stack >= %2k', array(
        1 => $latestVer,
        2 => self::MINIMUM_THREAD_STACK,
      ));
    }

My thread_stack is set to 512K

mysql> show variables like 'thread_stack';
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| thread_stack  | 524288 |
+---------------+--------+

I commented out the check, and got farther along, but got an "Access Denied" error later in the process while executing a "CREATE FUNCTION". I added the MySQL "Create Routine", "Alter Routine" and "Execute" privileges using WebMin and re-tried the upgrade (after restoring my database). After this, the upgrade was successful.

I'm not sure if the thread_stack check error was due to the insufficient privileges for 4.3 (which were sufficient for 4.2 installs and upgrades to work). I'm tossing this out mostly for others that might be upgrading. I can open an issue if the thread_stack check is a bug. I did find http://issues.civicrm.org/jira/browse/CRM-12056 which hinted at a problem with the check, but was with MySQL 5.0.

I see that function in CRM/Core/DAO.php:

  /**
   * Lookup the value of a MySQL global configuration variable.
   *
   * @param string $name e.g. "thread_stack"
   * @param mixed $default
   * @return mixed
   */
  public static function getGlobalSetting($name, $default = NULL) {
    // Alternatively, SELECT @@GLOBAL.thread_stack, but
    // that has been reported to fail under MySQL 5.0 for OS X
    $escapedName = self::escapeString($name);
    $dao = CRM_Core_DAO::executeQuery("SHOW VARIABLES LIKE '$escapedName'");
    if ($dao->fetch()) {
      return $dao->Value;
    } else {
      return $default;
    }
  }

When I upgraded, I moved the entire civicrm directory from sites/all/modules to a directory outside the web root.

I *DID* have to restart Apache after I commented out the code block before that change took effect...

php-pecl-apc-3.1.9-2.el6.x86_64

I did a little digging, and it seems that APC *should* have picked up that the file changed. I've added

apc.stat = 1
apc.stat_ctime = 1

to my /etc/php.ini to see if it behaves better the next time around.