Migrating a site from the Aegir hostmaster to a remote server fails with:

Drush command terminated abnormally due to an unrecoverable error. Error: Cannot redeclare _PEAR_call_destructors() (previously declared in /var/aegir/platforms/piglet-ourpowerbase-6.22-3.4.4/sites/all/modules/civicrm/packages/PEAR.php:773) in /var/aegir/platforms/ducky-ourpowerbase-6.22-3.4.4/sites/all/modules/civicrm/packages/PEAR.php, line 811

I'm not sure if this is a provision_civicrm error or a provision error. The code seems to be including CiviCRM files on both the source server and the target server (hence, the same files (with different paths) are being included, which will clearly cause a PHP error.

Comments

jmcclelland’s picture

Status: Active » Closed (cannot reproduce)

Woops. Scratch that. I removed my own custom provision code and re-ran and did not have the problem. Sorry! Must be in my own code.

jmcclelland’s picture

For the record, I fixed the problem by replacing my calls to civicrm_initialize() with calls to _civicrm_init() (provided by civicrm.drush.inc).

jmcclelland’s picture

That didn't quite fix the problem as it turns out. Some sites are still failing with the same error.

I've now tried adding a sleep(5) call to the top of my custom post_provision_verify function with the theory that there is some race condition happening.

jmcclelland’s picture

Status: Closed (cannot reproduce) » Active

I'm re-opening because I've finally traced this problem.

In verify.provision.inc, in the drush_civicrm_post_provision_verify() includes the following lines:

 $crmPath = _provision_civicrm_get_package_path();
 $include_path = $crmPath . "/packages/:" . get_include_path( );
 set_include_path( $include_path );

If we are migrating, this code effectively puts both the packages directory for the platform we are migrating from and the packages directory for the platform we are migrating to into the include path.

This doesn't cause any problems, provided you don't try to include a file that resides in the civicrm packages directory after this code is called. And even then, it might not be a problem if whatever criteria PHP uses to choose from two different directories results in the file already included being included again (or ignored if include_once is used).

However, in the event that you do include a file from the civicrm packages directory, you'll get the error reported in this ticket (or something similar depending on which package is included).

Maybe this can be closed as wontfix, since the provision_civicrm code does not include any of these files and is therefore un-affected. Also, I'm not sure how it would be fixed. Presumably we want to be including the packages in the new platform, not the old one.

I've written the following hackish work around in our provision code:

 $inc_path = explode(':', get_include_path( ));
    // check for multiple civicrm package lines, which indicates we are migrating
    // and could encounter problems with packages being included twice
    // see: 
    $package_paths = preg_grep('#/sites/all/modules/civicrm/packages#',$inc_path);
    $last_path = null;
    while(list(,$path) = each($package_paths)) {
      // array_unique would be simpler, but we might have the same path, but one has
      // a trailing slash
      $path = trim($path, '/');
      if(!is_null($last_path) && $path != $last_path) {
        drush_log(dt("Found two different packages directories in include path. Not continuing with verify because it will cause errors."));
        return;
      } else {
        $last_path = $path;
      } 
    } 
bgm’s picture

I'm also having this issue on a Drupal 6 site with the "print" module.
More concretely, the "print_mail/print_mail.inc" file includes PEAR directly (outside any function):

// Include MIME library
@include_once('Mail/mime.php');

Presumably, Drupal is already bootstrapped at this point, so this gets run before we have time to change the include path.

bgm’s picture

Version: 6.x-1.0-beta1 » 6.x-1.x-dev
Status: Active » Fixed

Fixed in 6.x-1.x. Using hook_drush_init() to set the include path.
http://drupalcode.org/project/provision_civicrm.git/commit/baf7564

@ Jamie: if you still have a site on which you can test, can you review?

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

mrfelton’s picture

Status: Closed (fixed) » Needs work

Should this not be provision_civicrm_drush_init()? http://drupalcode.org/project/provision_civicrm.git/commitdiff_plain/baf... is in the wrong project namespace, which in mysetup causes a conflict with provision, which also implements hook_drush_init().

bgm’s picture

Isn't this already fixed in dev?

mrfelton’s picture

Status: Needs work » Fixed

Ignore, I see this has been corrected in latest dev.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.