CiviCRM Community Forums (archive)

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.

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

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

lobo

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:

  @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:

<?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:

[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?

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.

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... 

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.

#!/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...