Closed (fixed)
Project:
Provision CiviCRM
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
7 Feb 2012 at 20:54 UTC
Updated:
21 Sep 2012 at 17:51 UTC
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
Comment #1
jmcclelland commentedWoops. 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.
Comment #2
jmcclelland commentedFor the record, I fixed the problem by replacing my calls to civicrm_initialize() with calls to _civicrm_init() (provided by civicrm.drush.inc).
Comment #3
jmcclelland commentedThat 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.
Comment #4
jmcclelland commentedI'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:
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:
Comment #5
bgm commentedI'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):
Presumably, Drupal is already bootstrapped at this point, so this gets run before we have time to change the include path.
Comment #6
bgm commentedFixed 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?
Comment #8
mrfelton commentedShould 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().
Comment #9
bgm commentedIsn't this already fixed in dev?
Comment #10
mrfelton commentedIgnore, I see this has been corrected in latest dev.