503 Service Temporarily Unavailable on Magento after Clearing Cache - magento

Question

After clearing the cache in Magento under admin I am left with a 503 error, "Service Temporarily Unavailable". To be clear, this was caused by clearing the cache, 'var/cache'. This is not related to the Maintenance issue that can result in the same or similar problem (resolved by removed maintenance.flag file). There is no maintenance flag present in the root of the application. I've tried researching this issue and it seems like every post refers back to the Maintenance issue.
One thing to note; the 503 error is Web Server generated. The Maintenance issue returns 503 however it is the application (Magento) which returns it; so you see the application logo, links, et al..
I've checked the Web Servers logs and the following error is being generated:
539 access forbidden by rule, client: 165.225.138.177, server: , request: "POST /app/etc/local.xml HTTP/1.1"
I checked the file and it seemed obvious to me this was due to an ownership conflict; I changed the file owner however the problem persists.
Checking the Magento error logs, var/reports, I see the following error:
the error log (var/reports) reflects the following error: "Mage registry key "_singleton/" already exists"
the full error is:
a:5:{i:0;s:46:"Mage registry key "_singleton/" already exists";i:1;s:1157:"
#0 /data/html/app/Mage.php(223): Mage::throwException('Mage registry k...')
#1 /data/html/app/Mage.php(477): Mage::register('_singleton/', false)
#2 /data/html/app/code/core/Mage/Core/Model/Factory.php(81): Mage::getSingleton(false, Array)
#3 /data/html/app/code/core/Enterprise/UrlRewrite/Model/Url/Rewrite.php(94): Mage_Core_Model_Factory->getSingleton(false)
#4 /data/html/app/code/core/Enterprise/UrlRewrite/Model/Url/Rewrite/Request.php(114): Enterprise_UrlRewrite_Model_Url_Rewrite->loadByRequestPath(Array)
#5 /data/html/app/code/core/Enterprise/UrlRewrite/Model/Url/Rewrite/Request.php(58): Enterprise_UrlRewrite_Model_Url_Rewrite_Request->_loadRewrite()
#6 /data/html/app/code/core/Mage/Core/Model/Url/Rewrite/Request.php(116): Enterprise_UrlRewrite_Model_Url_Rewrite_Request->_rewriteDb()
#7 /data/html/app/code/core/Mage/Core/Controller/Varien/Front.php(165): Mage_Core_Model_Url_Rewrite_Request->rewrite()
#8 /data/html/app/code/core/Mage/Core/Model/App.php(365): Mage_Core_Controller_Varien_Front->dispatch()
#9 /data/html/app/Mage.php(684): Mage_Core_Model_App->run(Array)
#10 /data/html/index.php(83): Mage::run('default', 'store')
#11 {main}
";s:3:"url";s:1:"/";s:11:"script_name";s:10:"/index.php";s:4:"skin";s:7:"default";}
Can anyone provide any input on what could cause this?

Answer 1

First, and this is more for google posterity, make absolutely sure that
There's no maintenance.flag file in the root folder
That your error isn't web server generated (add a test.txt to the root and make sure you can access it)
Assuming you've done the above -- there aren't many places a stock Magento system will return a 503 error. Step 1 should be checking the following
PHP/Web Server error logs for exception messages
The Magento var/log/exception.log exception log
The Magento var/log/system.log exception log
The Magento var/report error report files
for any specific context about the error. It's very possible a third party extension is producing a 503.
Here's some things in a stock Magento install (CE and EE) that produce 503 errors (EE code excluded for vague fear of unclear licensing/fair-use)
If you're using Redis as a caching server and its locking system gets overwhelmed, the system can start producing 503 errors.
#File: app/code/community/Cm/RedisSession/Model/Session.php
// Limit concurrent lock waiters to prevent server resource hogging
if ($waiting >= $this->_maxConcurrency) {
// Overloaded sessions get 503 errors
$this->_redis->hIncrBy($sessionId, 'wait', -1);
$this->_sessionWritten = TRUE; // Prevent session from getting written
$writes = $this->_redis->hGet($sessionId, 'writes');
if ($this->_logLevel >= 4)
{
Mage::log(
sprintf("%s: Session concurrency exceeded for ID %s; displaying HTTP 503 (%s waiting, %s total requests)\n %s (%s - %s)",
$this->_getPid(),
$sessionId, $waiting, $writes,
Mage::app()->getRequest()->getRequestUri(), Mage::app()->getRequest()->getClientIp(), Mage::app()->getRequest()->getHeader('User-Agent')
),
Zend_Log::WARN, self::LOG_FILE
);
}
require_once(Mage::getBaseDir() . DS . 'errors' . DS . '503.php');
exit;
}
The PayPal IPN controller endpoint will throw a 503 if it can't find an order
#File: app/code/core/Mage/Paypal/Model/Ipn.php
if (empty($this->_order)) {
// get proper order
$id = $this->_request['invoice'];
$this->_order = Mage::getModel('sales/order')->loadByIncrementId($id);
if (!$this->_order->getId()) {
$this->_debugData['exception'] = sprintf('Wrong order ID: "%s".', $id);
$this->_debug();
Mage::app()->getResponse()
->setHeader('HTTP/1.1','503 Service Unavailable')
->sendResponse();
exit;
}
//...
}
Enterprise Edition can return a 503 in
app/code/core/Enterprise/Staging/Model/Observer.php
if a content staging configuration value is true.
EE can also return a 503 in
app/code/core/Enterprise/WebsiteRestriction/Model/Observer.php
If you're running in private sales mode and not authorized to see the sale.

Answer 2

I have corrected this issue. After some digging I finally found a Stack post (among many on the same subject) that had the following solution. You can read the post here:
https://magento.stackexchange.com/questions/51598/mage-registry-key-singleton-weee-observer-already-exists
It was suggested to execute these commands:
php -f shell/compiler.php disable
php -f shell/compiler.php clear
php -f shell/compiler.php compile
I toyed with this; including enable/disable and then I deleted the cache, var/cache. When I re-ran the page it worked.
A big thank you to everyone who posted; I feel like everything helped as I ruled out issues and found this resolution.

Answer 3

Additionnally to what has been already proposed, you might want to check that your server has free disk space. I just ran into the issue and it took me 15 minutes to realize the only issue was free space after an automated backup.