2011-01-17 11 views
10

そのマシン上で動作している別のインスタンスを認識し、それと通信してから終了する必要があるプログラムを作成する必要があります。私は、Linuxでこれを行う標準的な方法があるかどうかを知りたい。同じプログラムの他のプロセスをプロセスに認識させる方法

私の最初の考えは、プログラムのPIDを含んでいるファイルを書き、プログラムが実行されるたびにそのファイルを探すことでしたが、そのファイルの "正しい"場所と名前はどこですか?より良い、またはより "正しい"方法がありますか?

私は、ユーザーがそれを実行しようとしたと伝えなければなりませんが、別のインスタンスがあるので、ジョブを引き継いで終了します。私はSIGUSR1のようなシグナルを送ることを考えましたが、それはユーザーが第2のプロセスを実行した場所からのX11ディスプレイのような、より多くの情報を送ることを許しません。この情報を送信するには?

プログラムはGtkとリンクしているので、glibを使用するソリューションはOKです。

答えて

10

これを達成する一般的な方法は、pidをファイルに入れることです。デーモン(「システムプログラム」)の場合、そのようなファイルを置く共通の場所は/var/run/PROGRAM.pidです。ユーザープログラムについては、ユーザーのホームディレクトリにpidファイルを隠しておきます(プログラムにも設定ファイルがある場合は、設定ファイルとpidファイルをホームディレクトリのサブディレクトリに配置します)。

「マスター」インスタンスへの情報の送信は、通常、ローカルソケットと呼ばれるUnixドメインソケットを使用して行われます。ソケットを使用すると、pidファイルは必要ありません(ソケットをリッスンする人がいなければ、プロセスはマスターだと認識しています)。

+3

pidファイルだけではほとんど役に立たないです。アプリケーションがクラッシュした場合、pidファイルが削除されないため、手動で削除する必要があります。より良いオプションは、プロセスが何とか終了したときにOSが常にロックを解除するため、pidファイルをロックすることです。 'ls -la'を実行することでロックを見ることはできません。 Unixドメインソケットだけで十分です。 –

+0

@Maxim:False。 'unlink(...)'は、ファイルが閉じられた後にファイルを削除します。だから 'fd = open(path、...); unlink(path); 'は、一時ファイルを持つ通常のトリックです。 – Alexandru

+0

@Alexandru:ほとんどの場合、一時ファイルではなくpidファイルについて議論していたという事実を忘れてしまった。アプリケーションが終了する前に、pidファイルを削除してはいけません。 –

9

Unixドメインソケット。最初のインスタンスを一時ディレクトリに作成し、それを介して他のインスタンスと通信させます。

+2

一時ディレクトリではない可能性があります -/var/runはソケットファイルではよく使われます。 –

5

一般的なアプローチは、PIDファイルを書き込むことです。 pidfile(3)ライブラリを確認してください。

1

これを行う方法はたくさんあります。提案した方法(PIDを含むファイルを使用)は有効なものであり、多くのアプリケーションで使用されています。

アプリケーションの構成ファイルには、PIDファイルのパスが含まれることもあり、ハードコードされたパスが使用されることもあります。通常、アプリケーションは/tmp/var(それらがuid 0で実行される場合)またはローカルディレクトリ(~/.application/)にPIDファイルを置きます。

あなたのPIDファイルを置く場所についての一般的な提案はありません。好きな場所を選んでください。

2

linuxには名前付きミューテックスまたはセマフォと同等のものがありますか?だからあなたはそれが 'ロックされている'かどうかを確認することができますし、すでにそこに1つを持っているユーザーに警告してそれを閉じることができますか?

このリンクからは意味がありますか? http://www.linuxquestions.org/questions/programming-9/named-mutex-in-linux-296816/

+0

名前付きセマフォは、複数のインスタンスの問題に対処する方法として機能するように思われますが、むしろ非正統なものです。 – lvella

+2

これはうまくいくが、マシン上のすべてのプロセス間で名前空間が共有され、同じ名前の名前付きセマフォを開いて他のユーザーがプログラムをDoSできるというのはむしろ醜いことである。個人的には、ランダム化された名前のないPOSIX名前付きセマフォー/共有メモリーを使用しないで、正しい特権を持つプロセスを除いて書き込み可能でない他の安全なチャンネルを通して名前を伝えることはありません。 –

1

確かにUnixドメインソケットを使用できます。私は、ほとんどのアプリケーション(DCOPやDBUSのような上位システムを使用しない)がこれらを使用していると思います。

Linux固有であれば幸いですが、「抽象名前空間」UNIXソケットを使用できます。これらはファイルシステムに存在する必要がないので、かなり良いです。

プログラムがユーザー指向の場合は、マルチユーザー対応である必要があります。 1人のユーザーが別のユーザーのアプリケーションのコピーで動作を開始できないようにし、ユーザーがDoSできないようにセキュリティを確保する必要があります(例:ユーザーAのプログラムのコピーがハングした場合、 Bが始まるから?)。

+0

私は、ユーザーの家の中にファイルを保存すると、他のユーザーとの干渉を防ぐことができると思います。 – lvella

+0

これは可能な実装の1つです。 – MarkR

関連する問題