Диагностика

Материал из Eludia
Перейти к: навигация, поиск

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

Общие соображения

Неработоспособность WEB-приложения – это либо недоступность сервера, либо ошибка при обработке запроса. Надеемся, что, увидев надпись "Невозможно отобразить страницу", вы не звоните в службу техподдержки производителя браузера, а разбираетесь в ситуации самостоятельно. Например, генерируете запрос на проблемный адрес при помощи telnet или используете какой-либо нехитрый, но удобный пробник вроде WEBbug. Тут возможны 2 варианта: либо ответ есть, либо его нет.

Нет ответа

Отсутсвие ответа обычно означает, что либо вы перепутали адрес, либо либо WEB-сервер недоступен (а ping пробовали?) или заглушен, либо не слышит запросов из-за неправильной конфигурации (например, в директиве VirtualHost указан порт, не упомянутый в Listen). Впрочем, случается, что при вычислении ответа происходит вечное зацикливание или просто процедура выполняется слишком долго – это видно по загрузке процессора (сервера, разумеется). При первом запросе к новой системе может создаваться множество объектов БД, что может занять минуту-другую, но бесконечный цикл вы можете устроить только самостоятельно и несколько позже – тут нужно будет анализировать ваш код.

Ответ ошибочный

Теперь рассмотрим тот случай, когда ответ имеется, но вместо ожидаемого кода 200 (ОК) вы получили 500 (Internal Server Error). Тогда надо читать logs/error.log – там содержится описание ошибки с полным стеком вызовов. Чаще всего фатальные ошибки бывают связаны с отсутствием какого-либо стороннего модуля, используемого приложением. Если это так, следует установить требуемый модуль и перезапустить WEB-сервер. Возможно также, что модуль установлен, но не прописаны параметры конфигурации, например, SMTP-сервер. Тогда надо отредактировать conf/httpd.conf и тоже перезапустить WEB-сервер. Похоже, под Win32 после восстановления из hibernate происходит нечто некорректное на уровне DBD::mysql, в результате чего самые безобидные запросы вызывают необъяснимые ошибки. Это не страшно – достаточно перезапустить сервисы. В любом случае, имея перед глазами номер строки и имя проблемного файла, можно вычислить источник проблемы и ликвидировать его.

Наиболее неприятная ситуация имеет место, когда в logs/error.log не остаётся сообщения об ошибке. Его можно поискать в корневом error.log, но в таких случаях там тоже, как правило, оказывается пусто. Это означает, что некая операция вызвала неотлавливаемый крах дочернего httpd-процесса. Такая неприятность может быть вызвана только конфликтами бинарных библиотек. Единственный способ узнать причину сбоя – запустить Apache с параметром -X с консоли: в этом случае он работает в однозадачном режиме и сообщение об ошибке не может пролететь мимо stderr. Самое обидное – когда сам по себе параметр -X ликвидирует симптомы: корень зла остаётся ненайденным, а функционировать система в однозадачном варианте не должна по соображениям эффективности. Однако само по себе такое стечение обстоятельств говорит о том, что налицо проблема конкурентности: либо вы задействовали библиотеку, которая в принципе не может корректно функционировать из-под множественных дочерних процессов Apache, либо вы создаёте на этапе загрузки WEB-сервера (например, в BEGIN-блоке Config.pm), а затем используете в порождённых httpd какой-то глобальный объект, который имеет жёсткую привязку к родительскому процессу. Такое явление, в частности, наблюдалось при использовании старых версий Eludia.pm совместно с DBD::Oracle. Если вы не собиретесь экспериментировать с бинарными (XS) модулями, например, новыми DBD-драйверами, то подобная опасность вам наверняка не грозит, но знать о ней не мешает.

Персональные инструменты
Пространства имён

Варианты
Действия
Навигация
Разработчику
Администратору
Инструменты