私は両方のコンテキストで尋ねています:技術的およびスタイリスト。
アプリケーション/デーモンは/opt/my_app/run/
にpidfileを保持できますか?
そうすることは非常に悪いですか?
私の必要はこれです:私のデーモンは特定のユーザーの下で実行され、実装者は/var/run
、chown、chgrpの新しいディレクトリをmkdirして、デーモンを実行する必要があります。 pidfileを(デーモンに対して)ローカルに保つほうが簡単だと思われます。
/opt/my_app/whatever
などのアプリケーションインストールディレクトリにpidfileを配置しません。このディレクトリは、読み取り専用でマウントしたり、マシン間で共有したり、変更を侵入の試みとして扱うデーモンによって監視したりできます。
Pidfilesの通常の場所は/var/run
です。ほとんどのユニックスは、ブート時にこのディレクトリを消去します。 Ubuntuでは、これは/var/run
インメモリファイルシステム(tmpfs)によって実現されます。
ルートとして実行しているスクリプトからデーモンを起動する場合、サブディレクトリ/var/run/gmooredaemon
を作成し、デーモンを実行しているユーザーにsu
ingしてからデーモンを起動してデーモンを起動させます。
最近の多くのLinuxシステムでは、rootとして実行されていないスクリプトまたはランチャーからデーモンを起動する場合、/run/user/$UID
にpidfileを置くことができます。これは、従来の/var/run
と同等のユーザーごとのものです。ランチャーのルート部分、またはルートとして実行されているブートスクリプトがディレクトリを作成する必要があることに注意してください(人間のユーザーの場合、ユーザーがログインしたときにディレクトリが作成されます)。
それ以外の場合は、/tmp
または/var/tmp
の下の場所を選択しますが、pidfileの名前は誰でも書き込み可能なディレクトリにある場合は一意に決定できないため、これにより複雑さが増します。
いずれにせよ、ディストリビューターまたは管理者がpidfileの場所を簡単に変更できるようにします(コマンドラインオプション、およびおそらくコンパイル時オプション)。
/ optは「自己完結型」アプリケーションのインストールに使用されるため、ここでは何も問題はありません。 /opt/my_app/etc/
を構成ファイルに使用し、/opt/my_app/log/
をログに使用するなど-この種のアプリケーションの一般的な方法。
これにより、すべてのパッケージマネージャーのパッケージを維持する代わりに、TGZファイルとしてアプリケーションを配布できます(ubuntu
をタグ付けしたため、少なくともDEB)。社内のアプリケーションや、環境をきめ細かく制御できる状況では、これをお勧めします。理由は、安全性があなたが中に入れているものよりも高い場合は意味がないということです(アプリケーションをパックするのに必要な作業は、アプリケーションを書くのに必要な努力をEclipseするべきではありません)。
Pidファイルの場所は構成可能でなければなりません。/var/runはpidファイルの標準であり、/ var/logはログの標準です。しかし、デーモンは、いくつかの構成ファイルでこの設定を上書きできるようにする必要があります。
スクリプトをルートとして実行していない場合のもう1つの規則は、~/.my_app/my_app.pid
にpidfileを配置することです。ホームディレクトリは誰でも書き込めないため、この方法はより簡単ですが、安全です。