NGINXは、詳細なデバッグログを含む幅広いデバッグの機能を持ちます。
注意
ほとんどのデバッギングの虫はNGINXが –with-debug 設定引数と一緒にコンパイルされた時にだけ有効化されます。
詳細はドキュメントのデバッグログ を見てください。
デバッグログを有効にするには、–with-debug設定オプションと一緒にNGINXをコンパイルし、デバッグレベルをerror_logディレクティブ内で設定する必要があります。
debug_connection ディレクティブを使って特定のアドレスからの接続のみをデバッグすることも可能です。
注意
難しい場合(例えば、問題に関係したイベントメソッドのデバッグ)はグローバルのerror_logの中でデバッグレベルを設定することで完全なデバッグログを取得することは良い考えです。
コアダンプを取得するには、通常OSを調整する必要があります。Though NGINX simplifies some typical cases and usually adding
worker_rlimit_core 500M;
working_directory /path/to/cores/;
to nginx.conf is enough. そして、いつものようにバックトレースを取得するために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メッセージという結果になります。To debug add
debug_points abort;
to nginx.conf and configure core dumps (see above). これは一度NGINXがリークを検出すると、abort()call とコアダンプに繋がるでしょう。
Something like this in gdb should be usefull (assuming 456 is connection number from error message from the process which dumped core):
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;