私は現在、さまざまな方法で互いに依存する4つのプロセスで構成されたアプリケーションを維持しています。現在のプロセスは、次のような真珠を含むかなり「洗練された」bashスクリプトを介して起動、停止、および監視されます。
# And another rather dirty way to identify the node Api
# process by knowing the filename that is given to node.js.
# Keep in mind not to kill the retrieved process directly, but
# check the running user and the used port to make sure you
# actually got the correct process.
findApiProcessId() {
local pid=`ps ax | grep node | grep api/server\.js | cut -c -5`
if [ $pid ]
then
echo $pid
else
echo -1
fi
}
同様の方法で他のプロセスを確認してください。
これでこのプロセス管理を完全に再設計できますが、正直なところ、どこから始めるべきかわかりません。私が監視する必要があるプロセスは次のとおりです。
- lighttpdは「安定した」PIDファイルを管理します。
- mongodは信頼できないように見えるpidファイルを管理します。時には、まったく異なるプロセスに属するpidを指すこともあります。
- いくつかのpidファイルを保持しようとしたが悲惨に失敗するnode.jsインスタンス(nohupを使用して実行)が複数あります。
コマンドラインから個々のプロセスを開始および停止し、状態を照会できる必要があります。アプリケーションのさまざまな「グループ」に対して、さまざまなディレクトリでプログラムを複数回実行できる必要があります。子プロセスは、現在の作業ディレクトリの構成ファイルを確認し、実行中の他のインスタンスをブロックせずにそのポートを「選択」できます。
私の最初の考えは、PythonやCで単純なプロセスホストを書くことでしたが、これはやや過剰だと思います。だから既存のツールを探していましたが」Linuxプロセスホストツール「有益なものを開示しないでください。
それでは、複数のサブプロセスを監視できる「標準」プロセスホストツールはありますか?
答え1
どうですか?runit
、「サービス監督によるUNIX初期化方式」?
あなたの要件を満たしていると思います。
- runitのサービス監督は、スーパーバイザプロセスによって自動的に実行されるように設計されたサービスデーモンへの依存関係を解決します。もっと)
- 実行中のサービスの確認は、次の方法で行うことができます。
sv status service
- すでにたくさんのことがありますサービス定義、使いやすく、独自のものを構築するための素晴らしいリソースです。
- さまざまなディストリビューション用にパッケージ化されており、非常に成熟しています(
lighttpd
Wikiページがありますrunit
、また見ることができますこれらの実行スクリプトには以下が含まれますlighttpd
。mongodb
) - さまざまなデーモンバリエーションに対応できます(例:node.jsはまったく問題を引き起こしません。)
答えられない「いくつかの変更されたサービス」巧妙な方法で問題を解決するには、もちろんサービスを個別に定義できます。 (いくつかのきれいなシンボリックリンクがある可能性があり、パスワードソリューションを確認することもできますが、ここで賢く努力するのが良いアイデアかどうかはわかりません。メンテナンス性)
編集する このArchWikiページ提供クイック概要おそらく、runit
このページより始めるのが良い場所でしょう。
答え2
pidof
pgrep
これをスクリプトで書いて疑わしい慣用語を避けたい場合は役に立ちますps | lots | of | things
。 uid、gid、ppid、最も古い、最新などでフィルタリングすることもできます。
このコマンドは、kill -0 $pid
特定のプロセスIDが存在することを確認するために使用できます。
異なるディレクトリに複数のインスタンスがあり、それらの違いがわからない場合は、問題が発生する可能性がありますps
。プラットフォームによっては、linux checkなどのcwdを介して簡単に区別できます/proc/$PID/cwd
。
# pgrep httpd
9483
9492
9493
9497
# head -1 /usr/local/apache2/logs/httpd.pid
9483
# kill -0 `head -1 /usr/local/apache2/logs/httpd.pid` && echo $?
0
# ls -l /proc/9483/cwd /proc/9483/exe
lrwxrwxrwx 1 root root 0 2013-01-30 19:40 /proc/9483/cwd -> /
lrwxrwxrwx 1 root root 0 2013-01-30 19:37 /proc/9483/exe -> /usr/local/apache2/bin/httpd
(申し訳ありませんが、Apacheの$ CWDはそれほど面白くありません...)
また、netstat
以下を助けることができます:
# netstat -plnt | grep :80
tcp 0 0 192.168.123.123:80 0.0.0.0:* LISTEN 9483/httpd
PIDファイルの管理に精通していないプロセスを監視するための起動スクリプトの一般的なトリックは、ビデモン/非フォークモードでバックグラウンドジョブとしてファイルを起動することです&
(明らかに、プログラムにはビデモンフラグ(時々モードinetd
とも呼ばれる)が必要です) )、そして$!
PIDファイルに直接書き込みます。
pstree
プロセス層を追跡するのに便利なツールです。
# pstree -lnp 9483
httpd(9483)-+-rotatelogs(9484)
|-rotatelogs(9485)
|-rotatelogs(9486)
|-rotatelogs(9491)
|-httpd(9492)
|-httpd(9493)-+-{httpd}(9495)
| |-{httpd}(9496)
| |-{httpd}(9498)
| |-{httpd}(9499)
| |-{httpd}(9502)
| |-{httpd}(9504)
[... lots more threads snipped ...]
最後の手段として、lsof
マルチプラットフォームツールを使用して、ファイル、接続、またはPIDで状況を追跡します。
標準プロセスマネージャタイプシステムの場合は、DJBを確認してください。デーモンツールパック。彼のウェブサイトはhttp://cr.yp.to/daemontools.html、ドキュメントは正直少し遅いかもしれませんが、チュートリアルに似たページがたくさんあります。
以下は未使用のいくつかの選択肢です。https://serverfault.com/questions/192302/alternative-to-daemontools-djbtools-to-supervise-unix-processes