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.
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/memcache.so’ – /usr/lib64/php/modules/memcache.so: 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 memcached.so file does, but memcache.so file does not!
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!
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|
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:
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.