unicornで走るrailsアプリケーションをデバッグする

unicornでバックグランドで走るようになっている場合、普通のpryのようなブレークポイントを置いて、対話型のインターフェースでデバッグすることが出来ない。

これを可能にできそうだったのが
blog.hello-world.jp.net
これだった。

(バイト先では権限がなくて新しいライブラリをインストールできるか微妙なのだが、)さっそく使ってみるべく、自宅のパソコンにもunicornを導入して、pry_remoteをインストールしてみた。
unicornの導入自体は
qiita.com
このページの前半を参考にやった。ただし、Unicornの起動に必要なrake unicorn:startに対してrake unicorn:stopがうまく使えなかったので、

ps -ef | grep unicorn
kill -QUIT xxxxx

でプロセスを確認しながら止めた。

pry_remoteも公式の説明と同様に入れたが、pry-byebugを消さなくても使用することが出来た。

require 'pry-remote'

class WelcomeController < ApplicationController
    def index
        @parameter = "This is my website"
        binding.remote_pry
    end
end

これで、そのページへのアクセスをかけた際に、

bendle exec pry-remote

でブレークポイントを見に行くことが出来る。（ロード中に行わないとエラーになる。）

このpry_remoteの最大の弱点はビューにブレークポイントが置けないことで、pryに比べるとだいぶ使い勝手が悪くなる。exitをつかったステップ実行には対応していなくて、exitでインターフェースから抜け出して、再度pry-remoteする必要がある。

また、動作もやや不安定に思われる。（一度入力しても反応がないなど。）

rails sでフォアグランドで走らせて通常のpryを使うのが最も効率の良い方法だと感じてしまった。そのためにはバックグランドで走るNginXとUnicornのプロセスを殺す必要がある。この2つのプロセスを殺して、果たしてアプリケーションがちゃんと動くのか、デバッグの後、ちゃんと両方のプロセスを再スタートできるのかが心配。

バックグラウンドでの動作を維持しながら、別のポートでフォアグラウンドで実行する方法はないものか。

もうちょっと手軽な代替案のしては、現行で使っているlogger.debugを使いつつ、出力先を新しいファイルにすることで、

require 'logger'

log = Logger.new('/tmp/log')

で、新しいloggerのインスタンスを作成して新しいログの保存先を指定する。これで、他のロガーの残したログとの混乱を避けることが出来る。