Где я могу найти ошибки времени выполнения приложения с помощью Nginx, Starman, Plack и Catalyst? - PullRequest
Новая
       44

Где я могу найти ошибки времени выполнения приложения с помощью Nginx, Starman, Plack и Catalyst?

3 голосов
/ 15 сентября 2010

Мне удалось успешно сервировать приложение Catalyst на моей машине разработки, используя Plack + Starman , используя сценарий демона, который я основал на сценарии, который я нашел в Silki Дэйва Рольски распространение.

Затем я настроил nginx для обратного прокси на моем сервере Starman и назначил статический каталог для nginx для обслуживания. Все идет нормально. Тем не менее, я в растерянности относительно того, где должно регистрироваться мое приложение STDERR. Он не достигает nginx (я полагаю, что это имеет смысл), но я не могу найти много документации относительно того, где Starman может регистрировать его - если где-нибудь. Я взглянул на модули промежуточного программного обеспечения Plack, но видел только опции для журналов доступа.

Может ли кто-нибудь мне помочь?

Ответы [ 3 ]

5 голосов
/ 15 сентября 2010

Это никуда не денется. Catalyst::Log отправляет данные на STDERR, а скрипт инициализации отправляет STDERR на /dev/null.

У вас есть несколько основных вариантов:

  1. Замените Catalyst::Log чем-то вроде Catalyst :: Log :: Log4perl или просто подклассом Catalyst::Log с переопределенным _send_to_log - любой из них позволит вам отправить запись выводить где-то, кроме STDERR.

  2. Напишите некоторый код, который выполняется на уровне PSGI для управления лог-файлом, и снова откройте для него STDERR. Я попробовал это, это было не очень приятно. Лог-файлы сложнее, чем выглядят.

  3. Вместо этого используйте FastCGI, и у вас будет поток ошибок, который отправляет выходные данные журнала на веб-сервер. Вы все еще можете использовать Plack через Plack :: Handler :: FCGI / Plack :: Handler :: FCGI :: Engine (я бы порекомендовал последнее, потому что FCGI :: Engine код намного новее и приятнее, чем FCGI.pm).

3 голосов
/ 14 октября 2014

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

У вас на самом деле есть еще одна опция, чем упоминал Хоббс.

Это не совсем «сценарий инициализации», который отправляет STDERR в / dev / null, это Starman.

Если вы посмотрите на исходный код Starman, вы обнаружите, что, если вы установите флаг --background, он использует MooseX::Daemonize::Core.

И как только вы узнаете это, его документация скажет вам, что он намеренно закрывает STDERR, STDOUT и STDIN и перенаправляет их в / dev / null, И что он принимает переменные окружения MX_DAEMON_STDERR и MX_DAEMON_STDOUT в качестве именфайлы для использования вместо этого.

Так что, если вы запустите сервер катализаторов с MX_DAEMON_STDERR, для которого задано имя файла, STDERR перейдет к этому файлу.

0 голосов
/ 14 апреля 2018

Сегодня Starman имеет параметр командной строки --error-log, который позволяет перенаправлять сообщения об ошибках в файл.

См. документацию starman:

- ошибка-журнал

Укажите путь к файлу, в который следует записывать журнал ошибок. Это позволяет вам по-прежнему иметь доступ к ошибкам при использовании --daemonize.

...