Linuxのパッケージをアップデートしたあとrestartが必要なプロセスを見つける方法 - Qiita
はじめに 脆弱性対応のためのアップデート作業というものは頻繁に発生するものですが、本番運用しているシステムではサービスへの影響を最小限にしたいものです。 アップデートした後、出来ることなら必要なプロセスだけリスタートさせることで済ませたいのですが、どのプロセスをリスタートすれば良いのか、そもそもOS再起動しないと反映されないものなのか、判断が付かない場合が少なくありません。 そのような場合のため、再起動が必要なプロセスを見つけたり、OS再起動が必要かどうかアドバイスしてくれるコマンドがあります。 Redhat系 「yum-utils」パッケージに入っている「needs-restarting」コマンドを使います。 # needs-restarting -h Usage: needs-restarting: Report a list of process ids of programs th
h2o と server_starter で graceful restart with Docker - blog.nomadscafe.jp
h2o はserver_starter経由のgraceful restartをサポートしているので試してみた。ついでにdockerで動かしてみた。 h2o/h2o 実際にwrkでベンチマークしながらコンテナにHUPシグナルを送り、graceful restartを行ってみたのが次の動画 左上がh2oをdocker経由で起動しているウィンドウ、HUPを受けてh2oのプロセスを入れ替えている様子がわかります。。左下はwrkの実行、右側はコンテナにHUPを送ってます。 HUPシグナルはdocker killを使って送ります。 $ docker kill --signal="HUP" $(docker ps |grep kazeburo/h2o|awk '{print $1}') wrkの結果はこんな感じ。エラーは出ていません vagrant@vagrant-ubuntu-trusty-64:~/
Go言語でGraceful Restartをするときに取りこぼしを少なくする
少し前にStarletにGraceful Restartが時たま上手く動かない問題を修正するpullreqを投げました。 原因は割り込みハンドラ内でexitを呼んでいたからでした。 「割り込みハンドラ内ではフラグを建てるだけ」 「メインのプログラム内でそのフラグを見て分岐する」という原則があるのですが、それを守るのは難しいということですね。 (しかし新たな問題を産んでしまいrevertされてしまいましたが・・・ まあ修正後のコードも考え方は一緒です。割り込みホント難しい・・・) このpullreqを取り込んでもらうときに再現実験をやってみたのですが、 Goでもちゃんと動くのかな？と気になったので Go言語でGraceful Restartをするで紹介した プログラムに同じテストをやってみました。 2017-01-22追記: Go1.8以降でGraceful Shutdownがbuild-i
ダウンタイム・ゼロを支える技術 in Go 2015.04.23 Fukuoka.go#7 @monochromegane | Stobo
このスライドは Markdown でプレゼンテーションが作成できるサービス Stobo で公開されています。
Server::Starterの0.17以下のバージョンでは特定の条件下でHUPを送ってもプロセスが入れ替わらないことがあった - 平常運転
要約 Server::Starterの0.17以下のバージョン(とStarlet)によって動かしているときに無限ループ等でいつまでも処理の終わらないリクエストが発生すると、アプリケーションプロセスの再起動のためのHUPシグナルをServer::Starterが正しく処理してくれないことがある。 この挙動によってアプリケーションプロセスが古いリビジョンで動かしてしまうなどの問題があって困っていたんだけど、気付いたら0.19でこの挙動が改善していた。 前提 perlでdaemontoolsを用いてアプリケーションプロセスを動かし、かつホットデプロイを実現しようと思ったときの有力な選択肢がServer::Starterによるstart_serverとStarletの組み合わせだと思う。start_serverとStarletは以下のような挙動を示す。 start_serverはHUPを受け取った
Webアプリケーションの無停止稼働
ポーリング、Ajax、Comet、Server Sent Events、WebSocket サーバPUSH方式の大雑把な比較
子供のプラグインの設定をgracefulに再読み込みする #fluentd のアウトプットプラグインをリリースしました - id:bash0C7の進捗 過去アーカイブ[〜2019-02-23]
fluent-plugin-config_reloaderという名前で作ってみまてます。 昨日のエントリーに書いたものから実用的になるように考えを進めてます。 設定ファイルの再読み込みだけに特化した シグナルをやめて、指定したパスにファイルをtouchすると再読み込みを行うようにした コード bash0C7/fluent-plugin-config_reloader · GitHub インストール Gemfileに下記を追記するか、 gem 'fluent-plugin-config_reloader' 直接突っ込むかしてください。 gem install fluent-plugin-config_reloader 設定 type config_reloader config_file child.conf reload_file reload.txt reload_file_watch_
![子供のプラグインの設定をgracefulに再読み込みする #fluentd のアウトプットプラグインをリリースしました - id:bash0C7の進捗 過去アーカイブ[〜2019-02-23]](https://cdn-ak-scissors.b.st-hatena.com/image/square/71b89beae944bf6bb3fce855e7914b87dd52bf65/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F12921228815714508769%2F12921228815723378915%2F1399424159)
私家版のgoでホットデプロイの仕組み、もしくは椅子もマサカリも投げられたくないときの気遣い : D-7 <altijd in beweging>
なんかごく一部に補足されているので、念のため軽く説明しておきます。 masahiro nagano@kazeburo某所のlestrratさんのgolangなアプリはhot-deployが可能になってる。サーバはserver_starter経由で起動されていて、バイナリ消してHUPを送ると自動でビルドしなおしてプロセスを入れ替えてくれる。便利 2014/04/30 12:18:31 これ、ベストな方法だとは思っていないんだけど、最初にこれを書いた当時の考え方は以下の通り： これは自分の部署で初めて 本番に設置するgoアプリである一次対応をする人は自分とは限らない細かいコード内容の修正はともかく、明らかなバグっぽいものの修正（例：SQL文の変更）などを自分以外の人間が施した後にサーバーを簡単に再コンパイル＋再起動するする方法がないと椅子が降ってくる事が容易に予想される Apache::Log
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
fluentd-server から serf 使って td-agent を再起動できるようにした : sonots:blog
Webアプリケーションの無停止稼働 - Server::Starter, Parallel::Prefork, Starlet を使って (SoozyConference 7 発表資料)