watch コマンドとは 定期的にコマンドを実行するコマンド。 crontabの実行結果がシェルに出る点がcronとは異なる。 watchコマンドの使い方
こちらも参考に。 httpdプロセスの起動、停止、再起動 - by shigemk2 404 Not Found graceful 親プロセスは USR1 または graceful シグナルを受け取ると、 子プロセスに現在のリクエストの処理の後に終了する (あるいは何もしていなければすぐに終了する) ように助言します。 親プロセスは設定ファイルを再読込して、ログファイルを開き直します。 子プロセスが徐々になくなるに従って、 新しい世代の設定による子プロセスに置き換えていきます。 そして、これらが新たなリクエストに即座に応答し始めます。 つまり、緩やかな再起動を行う。 restart HUP あるいは restart シグナルを親プロセスに送ると、 子プロセスを kill しますが、 親プロセスは終了しません。 設定ファイルを再読込して、ログファイル全てを開き直します。 その後、新しい子プロ
RailsサーバーのUnicornはmasterプロセスにUSR2シグナルを送ると、新しい設定・アプリのリロードを無停止で行うgraceful restartな動きをしてくれます。 この仕組を理解してなかったのでそれのメモ。 ドキュメントも何も見てない時の認識 現行のmasterが新しい設定・アプリをロードした新masterプロセスをforkする 新masterとそこから生えるworkerがreadyになって、新旧のUnicornが処理を行う 頃合いを見て旧masterは勝手に落ちる と思ってたんだけど、実際試してみても3のタイミングになっても旧masterがなかなか落ちてくれない。 旧masterのCPU利用率はだんだん下がってきているので、それがなくなったら落ちるのかと勝手に思ってたけどそうでもない。ウーンとなっててドキュメント見たら普通に書いてありました。 USR2を送った時の動き
ダウンタイム無しってすごい。 でも、そんな実行環境は今のところ必要ないので monitの監視程度まで試したら、passengerに移行するやもしれません。 USR2時に旧プロセスを停止する 設定 ruby/1.9.1/gems/unicorn-4.1.1/examples/unicorn.conf.rb や unicorn.conf.rb にサンプルがありますが before_forkというcallbackが使えて、下記のように旧プロセスに対してシグナルを発行することが可能です。 old_pid = "#{server.config[:pid]}.oldbin" if old_pid != server.pid begin sig = (worker.nr + 1) >= server.worker_processes ? :QUIT : :TTOU Process.kill(sig, F
たまにデプロイした際に Unicorn の再起動で失敗することがありました。 調べてみると「Capistrano によるデプロイ時に Unicorn の再起動に失敗することがある問題への対処」に書かれているのと同じ原因でした。 Unicorn の再起動時に、 Gemfile に新たに追加された gem を Bundler が読み込めていないことがわかった。 だから require している箇所で LoadError が発生Pする。 新しくなった Gemfile を Bundler がうまくロードできていないようだ。 元記事では Capistrano2 で run に環境変数を設定したものを文字列で渡して起動させているのですが、 ‘capistrano-bundler’ や ‘capistrano-rbenv’ を使っているので文字列で指定せずに環境変数を指定するやり方を調べてみました。 C
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く