503 Сервис временно недоступен на Magento после очистки кэша

Question

После очистки кеша в Magento под управлением администратора у меня осталась ошибка 503, «Услуга временно недоступна». Чтобы быть ясным, это было вызвано очисткой кеша, 'var/cache'. Это не связано с проблемой обслуживания, которая может привести к той же или подобной проблеме (разрешен удаленным файлом maintenance.flag). В корне приложения нет флага обслуживания. Я попытался изучить эту проблему, и кажется, что каждое сообщение ссылается на проблему обслуживания.

Следует отметить одно замечание; ошибка 503 генерируется веб-сервером. Проблема Maintenance возвращает 503, но это приложение (Magento) возвращает его; так что вы видите приложение логотип, ссылки и др ..

Я проверил журналы веб-серверов и следующее сообщение об ошибке генерируется:

539 access forbidden by rule, client: 165.225.138.177, server: , request: "POST /app/etc/local.xml HTTP/1.1" 

Я проверил файл и для меня это казалось очевидным из-за конфликта собственности; Я изменил владельца файла, однако проблема не устранена.

Проверка журналов ошибок Magento, var/reports, я вижу следующее сообщение об ошибке:

the error log (var/reports) reflects the following error: "Mage registry key "_singleton/" already exists" 

полной ошибки:

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";} 

Кто может предоставить любой вход на то, что могло привести к этому?

Answer 1

Во-первых, и это больше для Google потомству, чтобы быть абсолютно уверены, что

• Там нет maintenance.flag файл в корневой папке
• Это ваша ошибка не веб-сервер генерируется (добавить test.txt к root и убедитесь, что вы можете получить к нему доступ)

Предполагая, что вы сделали это, не так много мест запаса Magento система вернет ошибку 503. Шаг 1 следует проверить следующие

• PHP журналы ошибок сервера/Web для исключения сообщений
• Magento вар/Журнал/exception.log бревенчатого исключения
• Magento вар/Журнал/system.log бревенчатого исключения
• отчет об ошибке Magento var/report файлы

для любого конкретного контекста об ошибке. Вполне возможно, расширение третьей стороны производит 503.

Вот некоторые вещи в наличии Magento установки (CE и EE), которые производят 503 ошибок (EE код исключены за смутный страх неясного лицензирования/справедливого использование)

Если вы используете Redis в качестве кеширующего сервера, и его система блокировки становится перегруженной, система может начать производить 503 ошибки.

#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; 
} 

Контроллер конечных точек PayPal IPN будет бросать 503, если он не может найти заказ

#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 может вернуть 503 в

app/code/core/Enterprise/Staging/Model/Observer.php 

если конфигурация размещения содержимого значение истинно.

EE также может возвращать 503 в

app/code/core/Enterprise/WebsiteRestriction/Model/Observer.php 

Если вы работаете в режиме приватного продаж и не имеет права видеть продажу.

Answer 2

Я исправил эту проблему. После некоторого рытья я наконец нашел столбец Stack (среди многих по тому же вопросу), который имел следующее решение. Вы можете читать почту здесь: https://magento.stackexchange.com/questions/51598/mage-registry-key-singleton-weee-observer-already-exists

Было предложено выполнить следующие команды:

php -f shell/compiler.php disable 
php -f shell/compiler.php clear 
php -f shell/compiler.php compile 

я играл с этим; включая включение/выключение, а затем я удалил кеш, var/cache. Когда я снова запустил страницу, она сработала.

Большое спасибо всем, кто выложил; Я чувствую, что все помогло, поскольку я исключил проблемы и нашел эту резолюцию.

Answer 3

В дополнение к тому, что уже было предложено, вы можете проверить, что на вашем сервере имеет свободное место. Я просто столкнулся с проблемой, и мне потребовалось 15 минут, чтобы понять, что единственной проблемой было свободное пространство после автоматического резервного копирования.