Мое приложение для направляющих возвращает HTTP 500 для всех своих URL, но ничто не обнаруживается в файле журнала. Как я могу диагностировать проблему?
У меня есть приложение для направляющих, которое работает на рабочем сервере с Apache и Пассажиром Phusion. Приложение хорошо работает локально при использовании Полукровки, но каждый раз, когда я пытаюсь загрузить URL на рабочем сервере, оно возвращает HTTP 500. Я знаю, что сервер работает правильно, потому что я могу получить статические элементы приложения (например, файлы JavaScript, таблицы стилей, изображения) очень хорошо. Я также проверил состояние Passenger, и оно загружает приложение (это должно быть, так как Внутренняя страница Server Error приложения 500 возвращается, не только Apache по умолчанию один). Кроме того, когда я загружаю приложение через script/console production и сделайте что-то как app.get("/"), 500 также возвращается.
Проблема состоит в том, что нет ничего в файлах журнала для указания на проблему. production.log пусто. Журналы ошибок Apache не показывают проблем с Apache, также. Я озадачен относительно того, что продолжается, и я не уверен, как диагностировать проблему.
Я знаю, что, возможно, был немного неопределенен, но кто-либо может дать предложение на том, какова проблема может быть? Или по крайней мере путь я могу пойти о диагностировании его?
6 ответов
Ответом для этой конкретной ситуации была проблема с моим приложением. Один из классов модели использовал другое соединение с базой данных, чем остальная часть приложения. Это соединение с базой данных было неправильно настроено. Я думаю, что причина, по которой ничего не было записано в файлы журнала, заключается в том, что Rails выручил, не имея представления, что делать.
Поскольку другим может быть полезно увидеть, как я диагностировал эту проблему, вот мой мыслительный процесс:
- Проблема не могла быть в Apache: в файлы журнала Apache не было записано никаких ошибок.
- Вероятно, проблема заключалась не в Passenger: Passenger не записывал никаких ошибок в файл журнала Apache, и, похоже, мое приложение загружалось правильно, поскольку
пассажира-statusпоказывал, что оно загружено и он отображал страницу 500 внутренних ошибок сервера моего приложения (а не страницу Apache по умолчанию).
Отсюда я предположил, что в моем приложении что-то не так, что произошло очень рано на этапе инициализации, но это не было чем-то, что заставило приложение полностью выйти из строя и выдать исключение. Я покопался в группе Google Phusion Passenger и в конце концов наткнулся на этот полезный пост , в котором говорилось, что ошибка может быть связана с подключением к базе данных. Конечно же, удаление этой неправильно настроенной базы данных и всех ссылок на нее заставило приложение работать!
Вы пробовали запустить приложение локально с помощью Passenger?
Я недавно прочитал эту статью, Оптимизация программного обеспечения на C++ . В главе 2,3 Выбор операционной системы приведено сравнение преимуществ и недостатков 64 и 32-разрядной системы с некоторыми конкретными наблюдениями относительно Windows.
Марк Уилкинс уже отметил в этом потоке дополнительные регистры для вызовов функций. Другое интересное свойство 64-разрядной системы:
Набор команд SSE2 поддерживается на всех 64-разрядных ЦП и операционных системах.
SSE2 инструкции могут обеспечить отличную оптимизацию, и они все чаще используются, поэтому, на мой взгляд, это примечательная особенность.
-121--1639376-Некоторые модули шаблонов могут компилировать шаблоны, что приводит к высокооптимизированным преобразованиям. Возьмем, например, XslCompiledTransform в .NET.
-121--1384564-Я бы предложил вернуться на землю «Hello World» и создать наименьшее возможное приложение Ruby и загрузить его, чтобы узнать, есть ли проблема с Passenger или Ruby на сервере.
Возможно, это глупое предложение, но я предлагаю вам начать с увеличения уровня ведения журнала в производственной среде, пока вы тестируете. Сделайте это в config / environment / production.rb и используйте:
config.log_level = :debug
Это должно, по крайней мере, дать вам какую-то обратную трассировку, чтобы вы могли начать поиск проблемы. Если вы все еще получаете ничего - вы можете обнаружить, что у вас проблема с такой простой вещью, как отсутствующий гем / плагин на вашем рабочем сервере. Подобные вещи могут проявиться как ошибка «500» и просто не будут для вас слишком подробными.
Можете ли вы запустить набор тестов на своем рабочем сервере?
Попробуйте запустить приложение локально на Mongrel в производственном режиме, чтобы убедиться, что нет никаких странных проблем с этой конкретной средой. Если это сработает, значит, вы знаете, что это не проблема вашей кодовой базы. Поскольку ваши статические компоненты обслуживаются правильно, это говорит мне, что Apache работает нормально. Единственная оставшаяся передача в системе - это Пассажирский. На данный момент я бы сказал, что это неправильно настроенный пассажир. Вы должны опубликовать свой файл конфигурации Passenger и задать вопрос о ServerFault .
Пара вещей, которые стоит попробовать:
Вы изучили следующее из документации:
6.3.7. Файл журнала приложения My Rails не записывается в
Есть пара вещей, о которых вам следует знать:
По умолчанию Phusion Passenger запускает приложения Rails в производственной среде, поэтому обязательно проверьте production.log вместо development.log. См. RailsEnv для настройки . *
По умолчанию Phusion Passenger запускает приложения Rails как владелецenvironment.rb. Таким образом, файл журнала может быть записан только в том случае, если этот пользователь имеет разрешение на запись в файл журнала. Пожалуйста, выполните chmod или chown для вашего файла журнала соответственно.
Подробнее см. Переключение пользователей (безопасность).Если вы используете дистрибутив Linux на основе RedHat (например, Fedora или CentOS), тогда он возможно, вмешивается SELinux. Политика RedHat SELinux разрешает Apache только читать / писать каталоги с контекстом безопасности httpd_sys_content_t. Выполните следующую команду, чтобы дать папка приложения Rails этот контекст:
Вы проверили свой файл vhost или httpf.conf? Есть ли у вас какие-либо директивы ведения журнала?
Проверьте файл журнала apache верхнего уровня
Попробуйте установить для PassengerLogLevel значение 1, 2 или 3, как показано здесь http://www.modrails.com/documentation/Users% 20guide.html # _passengerloglevel_lt_integer_gt
Установлены ли у вас стоечные приложения?