こしごぇ

社内勉強会でUnicornについて発表したけどあまりの準備不足に全俺が泣いたので少しずつまとめていく〜その４

Unicornとシグナル(SIGNALSより)

マスタプロセス

HUP: 設定ファイルをリロードし、すべてのワーカーを実行中の処理の終了を待ってから再起動させる。もしpreload_appディレクティブが偽なら、ワーカーが起動する際にコードの変更を反映される。preload_appが真ならコードの変化は無視される(新しいコードをロードするためには、USR2とQUITを使うこと)。アプリケーションをリロードする時にGem.refreshが実行されるため、新しくインストールしたGemを使うことができるようになる。アプリケーションがUnicornで動作中に依存ライブラリをアンインストールすると、ワーカーが起動する際にアンインストールされたライブラリをロードすることができずに失敗する。

INT/TERM: ワーカープロセスも含めて、直ちに終了させる。

QUIT: ワーカーの処理を待ってから終了させる。

USR1: マスタとワーカーがつかんでいるログファイルを開き直す。

USR2: 実行中のバイナリを再実行する。新しいマスタプロセスが稼働したことを確認した後で、オリジナルのマスタプロセスを終了させるために別途QUITを送る必要がある。

WINCH: マスタプロセスは稼働させたまま、ワーカーだけを実行中の処理を待ってから止める。これは、デーモンモードの場合だけ有効。

TTIN: ワーカープロセスを一つ増やす。

TTOU: ワーカープロセスを一つ減らす。

ワーカープロセス

通常はワーカープロセスに直接シグナルを送ることはない。

INT/TERM: 実行中の処理の完了を待たずにワーカーを終了させる。マスタプロセスにWINCHを送らない場合、マスタプロセスはワーカーを新しく生み出す。

QUIT: 実行中の処理の完了を待ってからワーカーを終了させる。マスタプロセスにWINCHを送らない場合、マスタプロセスはワーカーを新しく生み出す。

USR1: ログファイルを開き直す。ただし、リクエストを処理中の間はログファイルを開き直すことはないため、ひとかたまりのログが分かれて記録される様なことはない。ワーカープロセスのユーザ・グループ切り替えサポートを利用している場合、ワーカープロセスに直接USR1シグナルを送ることはすすめられない。ログファイルのパーミッションの間違いがあるかもしれないし、ワーカーを再起動させることになるかもしれない。マスタプロセスにUSR1を送るのが妥当。

稼働中のUnicornを置き換える手順

マスタプロセスにUSR2を送る
新しいマスタプロセスが生成されたことをプロセスマネージャかPIDファイルで確認する
1. PIDファイルを使っているなら、古いプロセスのPIDファイル名には".oldbin"が追加されている
2. 新しいマスタプロセスと元々のマスタプロセスの2つが稼働していて、どちらに属しているワーカーでもリクエストを処理できる
古いマスタプロセスにWINCHを送って新しいマスタプロセスのワーカーでだけ処理させる
1. Unicornが対話的なターミナルにバインドされている場合、この手順は飛ばせる
古いワーカーを終了させて、新しいワーカーが稼働している状態
うまくいっている様であれば、古いマスタプロセスにQUITを送る
1. 何かがおかしいようであれば、古いマスタプロセスにHUPを送って再起動させ、新しいマスタプロセスにQUITを送って終了させる

unicorn master (old)
├ unicorn worker[0]
├ unicorn worker[1]
├ unicorn worker[2]
├ unicorn worker[3]
└ unicorn master
   ├ unicorn worker[0]
   ├ unicorn worker[1]
   ├ unicorn worker[2]
   └ unicorn worker[3]