3

Dave RolskyのSilkiディストリビューションで見つけたデーモンスクリプトを使用して、Plack+Starmanを使用して開発マシンでCatalystアプリをサーバー化することに成功しました。

次に、スターマンサーバーにリバースプロキシするようにnginxを設定し、nginxが提供する静的ディレクトリのエイリアスを作成しました。ここまでは順調ですね。ただし、アプリケーションSTDERRがどこにログを記録するのか迷っています。それはnginxに到達していません（私はそれが理にかなっていると思います）が、Starmanがそれをどこに記録しているのかについての多くのドキュメントを見つけることができません-どこにでも。Plackのミドルウェアモジュールを確認しましたが、アクセスログのオプションしか表示されませんでした。

誰かが私を助けることができますか？

4

3 に答える 3

5

それはどこにも行きません。Catalyst::Logはにデータを送信しSTDERR、initスクリプトはに送信STDERRしてい/dev/nullます。

基本的な選択肢がいくつかあります。

  1. Catalyst :: Log :: Log4perlのCatalyst::Logようなもの、または単にオーバーライドされたのサブクラスに置き換えます。どちらでも、ログ出力をSTDERR以外の場所に送信できます。Catalyst::Log_send_to_log

  2. PSGIレベルで実行されるコードを記述して、ログファイルを管理し、STDERRを再度開きます。私はこれを試しました、それはあまり快適ではありませんでした。ログファイルは見た目よりも難しいです。

  3. 代わりにFastCGIを使用すると、ログ出力をWebサーバーに送り返すエラーストリームが発生します。Plack :: Handler :: FCGI / Plack :: Handler :: FCGI :: Engineを介してPlackを引き続き使用できます（FCGI :: EngineコードはFCGI.pmよりもはるかに新しく、優れているため、後者をお勧めします）。

于 2010-09-15T19:43:11.293 に答える
3

質問されてから久しぶりですが、同じ問題にぶつかりました...

実際には、Hobbsが述べたよりも1つ多くのオプションがあります。

STDERRを/dev/ nullに送信しているのは、「initスクリプト」ではなく、Starmanです。

--backgroundStarmanのソースコードを見ると、フラグを付けると、が使用されていることがわかりますMooseX::Daemonize::Core。

そして、それを知ったら、そのドキュメントは、STDERR、STDOUT、およびSTDINを意図的に閉じて、それらを/ dev / nullにリダイレクトし、代わりに使用するファイルの名前として環境変数MX_DAEMON_STDERRおよびMX_DAEMON_STDOUTを使用することを示します。

したがって、MX_DAEMON_STDERRをファイル名に設定してCatalystサーバーを起動すると、STDERRはそのファイルに移動します。

于 2014-10-14T16:50:08.687 に答える
0

現在、Starmanには、--error-logエラーメッセージをファイルにリダイレクトできるコマンドラインオプションがあります。

のドキュメントをstarman参照してください：

- エラーログ

エラーログを書き込むファイルのパス名を指定します。これにより、を使用しているときに引き続きエラーにアクセスできます--daemonize。

于 2018-04-13T21:02:15.867 に答える