Magento – Fix Class ‘Mage’ Not Found and include(): Failed Opening ‘Mage.php’ Error

cm-redissessionee-1.14.1varien-autoload

We have some many error lines on httpd error log, about 10-15 errors for every day, on different time:

PHP Warning:  include(Mage.php): failed to open stream: No such file or directory in /var/www/html/lib/Varien/Autoload.php on line 94
...
PHP Fatal error:  Class 'Mage' not found in /var/www/html/app/code/core/Mage/Core/functions.php on line 244
...
PHP Fatal error:  Class 'Mage' not found in /var/www/html/app/code/core/Mage/Core/Model/Resource/Session.php on line 108

Any error not found related to the issue on Magento logs. Some times some customers cannot be login, is it result of the issue given above?

It seems these errors appeared after upgrading EE 1.13.1 to EE 1.14.1 month ago. Followed this one, but we have some difficulties to catch error as this error is only on live instance. Magento instance status:

  • Uses Redis for session, cache and fpc
  • Uses load balancer
  • about 2000 SKUs
  • about 20000 visits per day
  • Compilation mode is off

Issue is not permanent, it is available only some times (maybe peak time of the day)

Any help will be appreciated.

Update

Unknown and strange thing is I have set full permission to var folder (chmod 777 -R var/*) and issue has gone away. But var directory was be available for web-server user and group: magento logs, magento-connect, system backup was worked perfectly as a fact of valid permission of the folder. Consider this change while giving some diagnose.

Best Answer

I remember debugging a similar issue and it happened sometimes when the session was written during script shutdown from the destructor of the session model.

For some reason the Mage class was already unloaded at this time, so the autoloader tries to load Mage.php which is not in the include path (it gets explicitly required in index.php).

Unfortunately the problem solved itself mysteriously in my case and I still don't know how this class unloading could happen, it might have been a bug in PHP.

But closing the session explicitly with session_write_close() at the end of index.php might be a workaround.

Related Topic