はじめに

NGINXは、詳細なデバッグログを含む幅広いデバッグの機能を持ちます。

デバッグのログ¶

詳細はドキュメントのデバッグログ を見てください。

デバッグログを有効にするには、–with-debug設定オプションと一緒にNGINXをコンパイルし、デバッグレベルをerror_logディレクティブ内で設定する必要があります。

debug_connection ディレクティブを使って特定のアドレスからの接続のみをデバッグすることも可能です。

コアダンプ¶

コアダンプを取得するには、通常OSを調整する必要があります。しかし、NGINXは一部の一般的な場合を単純化し、通常は以下を

worker_rlimit_core  500M;
working_directory   /path/to/cores/;

nginx.conf に追加するだけで十分です。そして、いつものようにバックトレースを取得するためにgdbを実行します。たとえば、

gdb /path/to/nginx /path/to/cores/nginx.core
backtrace full

gdbバックトレースがシンボルテーブル情報が利用できないと警告する場合は、デバッグシンボルのために適切なコンパイラフラグを使ってNGINXを再コンパイル必要があるでしょう。

必要とされる正確なフラグは使用するコンパイラに依存します。もしGCCを使う場合は、フラグ-g がデバッグシンボルの含有を有効にします。更に、-O0 を使ってコンパイラの最適化を無効にすると、デバッガーの出力を簡単に理解しやすくするでしょう。

CFLAGS="-g -O0" ./configure ....

ソケットのリーク¶

時にはソケットのリークが発生します。これは通常NGINXのreload/restart/shutdown時にエラーログ内の[alert] 15248#0: open socket #123 left in connection 456メッセージという結果になります。デバッグするには、

debug_points abort;

をnginx.confに追加し、コアダンプを設定します (上を見てください)。これは一度NGINXがリークを検出すると、abort()call とコアダンプに繋がるでしょう。

gdbでのこのようなものは役に立つはずです (456 がコアをダンプしたプロセスからのエラーメッセージからの接続番号であると仮定):

set $c = &ngx_cycle->connections[456]
p $c->log->connection
p *$c
set $r = (ngx_http_request_t *) $c->data
p *$r

特に、p $c->log->connectionはログで使われている接続数を出力するでしょう。関係する行のためにdebugログをgrepすることが可能でしょう。例えば、

fgrep ' *12345678 ' /path/to/error_log;

助けを求める¶

デバッグの助けを求める場合は、以下を提供してください:

• nginx -V output
• 完全な設定
• デバッグログ
• (もしNGINXがシグナルで終了した場合は)バックトレース