3.1.5 - Fatal error: Cannot redeclare class pear

[bcobin]

Drupal 6.15

With 3.1.5 I now have two sites where going to Status Reports hangs up forever; on one site, I do get the following error message:

Fatal error: Cannot redeclare class pear in /home/[site]/public_html/sites/all/modules/civicrm/packages/PEAR.php on line 87

I believe it's the same problem on both sites.

Difficult to test insofar as these are production sites; this is new with 3.1.5 - 3.1.4 was OK.

[UPDATE - One of the sites seems OK now, although I haven't fully set up CiviMail there yet. The other site - with operating CiviMail - is still showing the error message on Status Reports. Not being able to check the Status Report on a site is a very bad thing.]

Any ideas here? Thanks much!

See also this thread: http://forum.civicrm.org/index.php/topic,10148.0.html

[CiviTeacher.com]

I have had problem with CiviMail status reports timing out.  But not with PEAR specifically.  Seems it's a change in 3.1.5 that caused this.  Look at the JIRA bug tracker to determine if any changes in 3.1.5 had anything to do with CiviMail reporting.  That may be your culprit.

Besides that, if these are production sites, you have to make a dev site to test, or bring the site down to debug.

I would also check your PHP execution time settings in your php.ini file.  Such a large process as the reporting can cause scripts to hang, and that may be the cause of the redeclare error.

[bcobin]

Thanks for the response, but timing out isn't the problem here (see the update.)

To recap:

With 3.1.5 installed, going to Status Report in Drupal causes:

Fatal error: Cannot redeclare class pear in /home/[site]/public_html/sites/all/modules/civicrm/packages/PEAR.php on line 87

This is immediate. And it's a big problem - not being able to see the site Status Report is a bad thing.

Otherwise, the 5,000+ emails went out fine and the bounce reporting looks OK too - very few "unable to parse bounce message" messages.

[Donald Lobo]

this is because you have another drupal module including PEAR also (and probably not including it via require_once)

find and disable the module to check the above theory

lobo

[bcobin]

This is a production site - the only thing that's changed since 3.1.4 is the upgrade to 3.1.5 - there have been no additional modules installed, nor any other upgrades.

3.1.4 didn't have the PEAR conflict, so I would think there has to be something in the upgrade that's different - any ideas? Thanks much...

[Donald Lobo]

no idea. u will need to trace it and figure out whats happening and why

lobo

[bcobin]

SOLVED! It's Plugin Manager.

I wasn't using it anyway - disabling it solves the problem.

Have submitted a bug report to the developer. Thanks for your input here, guys!

[Martin.Schwenke]

Drupal 6.15

With 3.1.5 I now have two sites where going to Status Reports hangs up forever; on one site, I do get the following error message:

Fatal error: Cannot redeclare class pear in /home/[site]/public_html/sites/all/modules/civicrm/packages/PEAR.php on line 87
...

I'm seeing a similar problem.  For me it is a conflict with recent changes to the Drupal print module.  They've added:

Code: [Select]

  @include_once('Mail/mime.php');
to a couple of places.  This causes the global version of Mail/mime.php from /usr/share/php to be pulled in.  Then CiviCRM pulls in the version from civicrm/packages/... .   Each tries to pull in their version of PEAR.php and a conflict ensues.  Presumably the PHP require_once() implementation (that's how PEAR.php is loaded) looks at the full file path and decides that CiviCRM is trying to load a different file (or actually, different files) to the one loaded by print.module.

Actually, I can confirm this using this test code:

Code: [Select]

<?php

$include_path = '/usr/share/php';
set_include_path( $include_path );

include_once('Mail/mime.php');

$include_path = '/home/martins/share/drupal6/modules/civicrm-3.2.0/packages:/usr/share/php';
set_include_path( $include_path );

include_once('Mail/mime.php');

?>

Running this results in:

Code: [Select]

[Thu Aug 12 20:06:49 2010] [error] [client 203.11.71.193] PHP Fatal error:  Cannot redeclare _PEAR_call_destructors() (previously declared in /usr/share/php/PEAR.php:773) in /home/martins/share/drupal6/modules/civicrm-3.2.0/packages/PEAR.php on line 811

which is the same problem I was seeing on my live system.

So, if there are 2 copies of a PHP package on a system, and the include path changes between attempts to load the file so that the 2nd version becomes "newly available", then bad things happen.

How can this be avoided in general, especially since CiviCRM wants to include its own version of some packages?

[Donald Lobo]

this is more of a PHP/PEAR packaging issue. We cannot assume that folks will have the latest version of all the PEAR packages we need in their "default" PHP library directory

I dont know what a reasonable solution for this problem is
lobo

[bcobin]

If Donald can't think of a solution, YIKES! I'm removing the "[SOLVED!]" from the title of the thread insofar as it clearly isn't yet.

[Martin.Schwenke]

this is more of a PHP/PEAR packaging issue. We cannot assume that folks will have the latest version of all the PEAR packages we need in their "default" PHP library directory

I dont know what a reasonable solution for this problem is

Yep, it is a tough one.  I wondered about moving civicrm/packages to the end of the include path and assuming that the packages globally installed on my server will be what CiviCRM wants.  That should work... but then I'll hit any incompatibilities that exist, even if the relevant packages weren't previously causing a conflict in any other modules.

For people like me who have a high degree of control over their server, the solution seems to be to carefully prune the civicrm/packages directory and replace things with symlinks.  A simple test shows that PHP resolves symlinks before comparing filenames to see if it has loaded a file before, so this should work.

Given that many of the packages are identical with what I have installed globally, wouldn't it be neat if PHP did the include_once() check based on a hash of the file contents?  I'll ask a PHP developer I know about this possibility...   

[Martin.Schwenke]

Given that many of the packages are identical with what I have installed globally, wouldn't it be neat if PHP did the include_once() check based on a hash of the file contents?  I'll ask a PHP developer I know about this possibility...   

Having thought about this, I can't see PHP going to a model like this, given the overhead (although comparing file size 1st would be a useful optimisation).  To make it workable, PHP would need some caching infrastructure... it doesn't seem trivial.

It also isn't even a medium term solution for CiviCRM.  If something like this happened in PHP 5.4 then CiviCRM wouldn't be able to rely on it for a couple of years...

Still, I like the idea - I think it can do no harm - so I will mention it to my friend... 

[technil]

What about doing a diff on the system PEAR.php and civicrm PEAR.php ? if it returns nothing, they are the same file, correct? then you can just use the system version and rename the civicrm version and replace it with a link to the system version?
Otherwise, you need to choose the civicrm one to be the primary, either by a symlink on the system level (ubuntu /usr/share/php/PEAR.php) pointing to the civicrm (/sites/all/modules/civicrm/packages/PEAR.php) or by declaring the civicrm (/sites/all/modules/civicrm/packages/PEAR.php) in the appropriate php.ini ( ubuntu: /etc/php5/apache2/php.ini) correct?

not everybody will have access to their php.ini or will be able to make a symlink in usr/share/php. Has there been any further discussion on this?

Thanks, and I know the topic/post is stale, but I just hit this bug over the past few days.

[Martin.Schwenke]

What about doing a diff on the system PEAR.php and civicrm PEAR.php ? if it returns nothing, they are the same file, correct? then you can just use the system version and rename the civicrm version and replace it with a link to the system version?
...

I just use the following script on every CiviCRM release.

Code: [Select]

#!/bin/sh

set -e

for i in Mail Mail.php PEAR.php ; do
    rm -rv packages/$i
    ln -sv /usr/share/php/$i packages/
done

It has worked for me so far...  but I realise that may change...   

[ucsendre]

I just use the following script on every CiviCRM release.

Hello Martin!

Would you be as kind as to explain it for me in which files did you include this script?
I can not set up my live site because of this error: Cannot redeclare _PEAR_call_destructors()

Thank you very much for your help!

Best regards,
Endre