Où puis-je trouver des erreurs d'exécution de l'application en utilisant Nginx, Starman, Plack et Catalyst?

Question

J'ai réussi à server mon application Catalyst sur ma machine de développement en utilisant Plack + Starman, en utilisant un script démon I basé sur celui que j'ai trouvé dans la distribution Silki de Dave Rolsky. J'ai ensuite configuré nginx pour inverser le proxy sur mon serveur Starman et alias le répertoire statique pour servir nginx. Jusqu'ici tout va bien. Cependant, je ne sais pas où ma demande STDERR est censée se connecter. Il n'atteint pas nginx (je suppose que cela a du sens) mais je ne trouve pas beaucoup de documentation sur l'endroit où Starman peut être en train de l'enregistrer - si c'est n'importe où. J'ai jeté un œil sur les modules Middleware de Plack, mais j'ai seulement vu des options pour les journaux d'accès.

Quelqu'un peut-il m'aider?

Answer 1

Ça ne va nulle part. Catalyst::Log envoie des données à STDERR et le script init envoie STDERR à /dev/null.

Vous avez quelques choix fondamentaux:

1. Remplacer Catalyst::Log avec quelque chose comme Catalyst::Log::Log4perl ou simplement une sous-classe de Catalyst::Log avec surchargée _send_to_log - l'un vous permettra d'envoyer la sortie d'enregistrement quelque part autre que STDERR.

2. Ecrivez un code qui s'exécute au niveau PSGI pour gérer un fichier journal et y rouvrir STDERR. J'ai essayé ça, ce n'était pas très agréable. Les fichiers journaux sont plus difficiles qu'ils ne le semblent. Utilisez plutôt FastCGI, et vous aurez un flux d'erreur qui renvoie la sortie du journal vers le serveur Web. Vous pouvez toujours utiliser Plack via Plack::Handler::FCGI/Plack::Handler::FCGI::Engine (je recommanderais ce dernier, car le code FCGI :: Engine est beaucoup plus récent et plus agréable que FCGI.pm).

Answer 2

Je me rends compte qu'il est longtemps que la question était posée, mais je viens de frapper le même problème ...

Vous avez fait une option plus de Hobbs mentionné.

Ce n'est pas tout à fait le "script d'initialisation" qui envoie STDERR à/dev/null, c'est Starman.

Si vous regardez le code source de Starman, vous découvrirez que, si vous lui donnez le drapeau --background, il utilise MooseX::Daemonize::Core. Et une fois que vous le savez, sa documentation vous indique qu'il ferme délibérément STDERR, STDOUT et STDIN et les redirige vers/dev/null, ET qu'il prend les variables d'environnement MX_DAEMON_STDERR et MX_DAEMON_STDOUT comme noms de fichiers utiliser à la place. Par conséquent, si vous démarrez votre serveur de catalyseur avec MX_DAEMON_STDERR défini sur un nom de fichier, STDERR ira à ce fichier.