PHP-FPM: Logging your errors

Ever need to log errors from PHP-FPM (or obtain more details)? I recently discovered the setting catch_workers_output within the etc/php-fpm.d/www.conf configuration file for php-fpm. By enabling this setting your php related errors will now be logged to your php-fpm error log file.

Screen Shot 2015-05-21 at 11.33.19 AM


Magento: Fatal error: spl_autoload() … line 132

So in dealing with Magento, I’ve ran across the following error:

Fatal error: spl_autoload(): Class Zend_Log_Exception could not be loaded …/lib/Zend/Log/Writer/Stream.php on line 132

We were attempting to use Memcache but each time it was enabled, the site would throw the above mentioned error on the page.  So we had it isolated to Memcache (disable Memcache in local.xml and error goes away) .  Reviewing the log files on the server (/var/log/system.log), we discovered the following:

ERR (3): Warning: ini_set(): Cannot find save handler ‘memcache’  in …app/code/core/Mage/Core/Model/Session/Abstract/Varien.php on line 56

The code was trying to use a memcache handler, but couldn’t find it.  A review of the PHPINFO() output further confirmed that memcache was not a recognized handler:


The session had a memcached handler, but not a memcache handler! 

On the server, I typed php on the command line and discovered the following:

PHP Warning:  PHP Startup: Unable to load dynamic library ‘/usr/lib64/php/modules/’ – /usr/lib64/php/modules/ cannot open shared object file:  No such file or directory in Unknown on line 0

So armed with that knowledge, I check the location to see if, indeed, the file exists.  I discovered the file does, but file does not!


So someone failed to recognize that there are two code bases for Memcache(d): 

The code appeared to be referencing the Memcache handler, but the only code base installed was the Memcached!  After discovery, the Memcache code base was installed on the servers and resolved the issues.

We were able to confirm the presence of the Memcache handler in the PHPINFO() output:


The error went away and we were able to proceed! 

Name and Location are Key!

She’s going to bark at you if you don’t treat her with respect!  That’s why it’s key to provide the proper name and proper location  for any Magento files.  Any time you see the following in Magento, assume you got your wires crossed and start rechecking everything in the path:


( ! ) Fatal error: Call to a member function load() on a non-object in C:\xampp\htdocs\MagentoE\app\code\core\Mage\Core\Model\Abstract.php on line 225
Call Stack
# Time Memory Function Location
1 0.0006 145344 {main}( ) ..\index.php:0
2 0.0041 330992 Mage::run( ) ..\index.php:87
3 0.0150 983144 Mage_Core_Model_App->run( ) ..\Mage.php:683
4 1.7253 7152144 Mage_Core_Controller_Varien_Front->dispatch( ) ..\App.php:354
5 1.7378 7894792 Mage_Core_Controller_Varien_Router_Standard->match( ) ..\Front.php:176
6 1.7412 8120632 Mage_Core_Controller_Varien_Action->dispatch( ) ..\Standard.php:250
7 1.9243 11377120 MyModule_Complexworld_IndexController->indexAction( ) ..\Action.php:419
8 1.9247 11400536 Mage_Core_Model_Abstract->load( ) ..\IndexController.php:10

In this instance My Module Class’ model was in the correct location, but the name of the class for the model didn’t match the expected name Magento was hunting for:

class MyModuel_Complexworld_Model_Resource_Eavblogpost
extends Mage_Eav_Model_Entity_Abstract


Can you spot the problem in the code above? Yeah, a simple misspelling can cause a lot of grief in this system!  This hasn’t bit me yet, but I anticipate it will the more I trudge through this mammoth system.