usion Passenger 3.0.19 + Nginxを使ってたとき、ログローテート関連の設定で少しはまったので、メモがてら。

始めに

Rails環境構築のとき、Passenger + Nginxの構成で環境構築をしました。
PassengerはNginxのモジュールとして動作させることができるので、Nginxのログローテーションと同じ設定にしておけば問題ないのかなと思ってたのですが、実際にローテーションさせると、Passengerが古いログファイルを出力ファイルの実態として追っていました。

Nginxのログローテーション設定

Nginxのログは、例えば以下のような形式で記述すればローテーションは可能です。
ここでポイントは、postrotate。

# vi /etc/logrotate.d/nginx

ローテーションの設定ファイルの中身

/usr/local/nginx/log/*log {
  daily
  rotate 30
  missingok
  notifempty
  compress
  sharedscripts
  postrotate
    [ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`
  endscript
}

設定の確認として、以下を試して文法に誤りが無いか、等確認

設定の確認

# logrotate -dv /etc/logrotate.d/nginx

強制的にローテーションさせる場合

# logrotate -f /etc/logrotate.d/nginx

passengerはNginxのモジュールとして扱われる形になるため、Nginxのpostrotateの記述で十分かなと思っていたのですが、passengerは依然として古い（passenger.log-日付）のファイルの実態にログの書き込みを続けていました・・・

Passengerのログローテーション設定

以下では、Nginxの設定で、Passengerのログをpassenger.logとして別途出力させるようにしたときの設定となります。
方法は2つあり、copytruncateを使う方法と、reset.txtを更新する方法があります。

copytruncateを使う場合

# vi /etc/logrotate.d/passenger

以下で、copyruncateオプションを付加します。

/usr/local/nginx/log/passenger.log
{
  daily
  rotate 30
  missingok
  notifempty
  compress
  sharedscripts
  copytruncate
}

この場合、copytruncateの特性上、若干のログのとりこぼしがある可能性があるのですが、Railsアプリの再起動も必要なく、passengerのログローテーションが可能。
私の場合、passenger.logのログはwarning以上のログレベルなので、通常は取りこぼしが極端に発生するほどの出力は得られないことが期待されているため、ありでした。※エラー頻発の場合、同じログが多くでますし。

Railsアプリの再起動をかけるようにする

以下のように、restart.txtを更新すると、Railsアプリの再起動がかかります。
欠点としては、Railsアプリ再起動後は若干Railsアプリの初回起動でレスポンスがもたつくのですが、多くの場合、ローテーションは午前4時とかに行われるので、日本限定のサービスという場合は許容できるサービスレベルでしょう。

# vi /etc/logrotate.d/passenger

以下では、postrotateの中身でRailsアプリを再起動しているのがポイントです。

/usr/local/nginx/log/passenger.log
{
  daily
  rotate 30
  missingok
  notifempty
  compress
  sharedscripts
  postrotate
    touch /path/to/app/current/tmp/restart.txt
  endscript
}

終わり

実際には、私のプロジェクトではRailsアプリログ自体のローテーションもこちらで制御したため、2つとも採用している1つのローテーションファイルを作っているのですが。