☰

これは、シミュレーションや理論ではなく、実際の生活であり、思ったほど華麗ではないので、停電後の孤児に対応する方法と、プログラムが処理できないときに再起動する方法について再び助けを求めました。正しい方法PIDファイルの存在

tag-icon • tag-icon linux systemd process pidfile
これは、シミュレーションや理論ではなく、実際の生活であり、思ったほど華麗ではないので、停電後の孤児に対応する方法と、プログラムが処理できないときに再起動する方法について再び助けを求めました。正しい方法PIDファイルの存在

そのような状況に遭遇しました。

  1. 停電
  2. 停電中のUPSバッテリー放電
  3. 停電によりラックのサーバーがシャットダウン
  4. 電力回復
  5. サーバーが起動してオペレーティングシステムが起動しています。
  6. systemdが私の役割を果たしています。
  7. そして

今一部のソフトウェア（システムサービス起動スクリプト）は深いブラックホールにあります。rylesの起動は、pidファイル（var / run）のプロセスにあるPID（番号）がまだ存在するかどうかを確認するのではなく、pidファイルが存在するかどうかによって異なります。 起動を拒否すると、不要なカスケード接続が発生する可能性があります。

今私の質問

  1. 私はソフトウェアデザイナーではないので、デザイナーが自分の作品を「正しくまたはそうする必要があるように」作業するようにしたり強制したりするソフトウェアマネージャーになることはできません。
  2. 特に、すべての更新後、すべてのサービスが期待どおりに機能していることを確認するために、最新の情報を引き続き確認することはできません。

3）この状況を世界的にどのように維持しますか？

a) its good idea o make a script and execute it on systemd service 
on each boot of server (linux kernel) to verify of pid file
processes existence ?  in case  of ps gone delete the pid file  

b) if so where such entry point for such service should be

c) how such script should handle the systemd services 
especially multiple .services file  location and the pid file named in those service files *with use of find or grep tools" .. 
as a blocking service ? it wold be a time cost solution ... 

d) or there is already better solution if so which one ? or some already made soft ?

maybe just hook after a init (process) ? and do just rm all *.pid ? by find -name *.pid ? exec rm ? it wold be 99% of job done :D

or do a systemd unit ExecStartPre= script for such each service to delete itself ? but it wold be time consuming to trace and edit service file and there is a "update" issue when sysyemd scirpt get changed by author ???

  1. それとも、サービススクリプトを中断せずに各システムサービスに対してPreExecSciptを一括/グローバルに実行できる独自のセクションはありますか？

添付：

最後の質問...私が本当の問題に対する解決策を尋ねるとき、あなたは（被害者として）私のために開発者の間違いについて私を罰しますか？

私は他のエラー、知識の欠如、または知識の欠如について責任を負いません。

PS2。

「毎日使用してインストールするすべてのソフトウェアのパフォーマンスを見ることはできませんが、このようなグループがあり、同様の問題があり、予防したいと思います。」

ps3。わかりました、いつ頃 走るフォルダ私はDEBIANと他のディストリビューションのルールを知っています。たとえば、次のようになります。

https://wiki.debian.org/ReleaseGoals/RunDirectory#How_to_transition_from_.2Fvar.2Frun_to_.2Frun_and_.2Fvar.2Flock_to_.2Frun.2Flock.3F

https://wiki.debian.org/ReleaseGoals/RunDirectory#Packages_using_.2Fvar.2Frun_and_.2Fvar.2Flock

https://wiki.debian.org/ReleaseGoals/RunDirectory#Why_can.27t_.2Fvar.2Frun_and_.2Fvar.2Flock_stay_under_.2Fvar.3F

これは、シミュレーションや理論ではなく、実際の生活であり、思ったほど華麗ではないので、停電後の孤児に対応する方法と、プログラムが処理できないときに再起動する方法について再び助けを求めました。正しい方法PIDファイルの存在

ソフトウェア開発者ハンドブックから

Keaのサーバーは起動時にPIDファイルを生成します。 keactrl はこれらのファイルを使用して、特定のサーバーが稼働していることを確認します。起動コマンドの実行時に1つ以上のサーバーが実行されている場合、出力は次のようになります。

keactrl start
INFO/keactrl: kea-dhcp4 appears to be running, see: PID 10918, PID file: /usr/local/var/run/kea/kea.kea-dhcp4.pid.
INFO/keactrl: kea-dhcp6 appears to be running, see: PID 10924, PID file: /usr/local/var/run/kea/kea.kea-dhcp6.pid.
INFO/keactrl: kea-dhcp-ddns appears to be running, see: PID 10930, PID file: /usr/local/var/run/kea/kea.kea-dhcp-ddns.pid.
INFO/keactrl: kea-ctrl-agent appears to be running, see: PID 10931, PID file: /usr/local/var/run/kea/kea.kea-ctrl-agent.pid.
INFO/keactrl: kea-netconf appears to be running, see: PID 10123, PID file: /usr/local/var/run/kea/kea.kea-netconf.pid.

通常のシャットダウン中にこれらのPIDファイルは削除されますが、システムクラッシュ後に残りのファイルとして残ることがあります。可能性はほとんどありませんが、システムが再起動すると、埋め込まれたPIDは実際にKeaとは関係のないプロセスを参照できます。このため、keactrlは実際にサーバーが稼働していなくてもサーバーが稼働していると判断します。この場合、keactrl出力にリストされているPIDファイルを手動で削除する必要があります。

したがって、私たちは不揮発性inodeでpidで終わります - > /usr/local/var/run

頑張ってT.Bestとも呼ばれるceph3us

ベストアンサー1

ご存知のように、システムの起動時にまだ存在するPIDファイルは、システムの新しい状態を正しく表していません。遅いPIDファイルは初期化プロセスを誤解し、破損する可能性があります。 PIDファイルを使用するための基本的な仮定は、電源が切断されたときに破棄されるように、そのファイルを揮発性パスに書き込むことです。

PIDファイルのルールは、/run揮発性ファイルシステムを使用するために必要なパスです。一般的にこれ一時ファイルシステム揮発性RAMにのみ存在します。歴史的な理由から、不揮発性ファイルシステムで実行という名前のシンボリックリンク/varもあります。代わりに、マウントされたファイルシステムは次のようになります。/run/var/run -> /run/usr/localいいえボラティリティが予想されます。また見てくださいファイルシステム階層標準。

リンク/実行

簡単な解決策は、/runサービスがPIDファイルを書きたい場所に接続することです。リンクされたディレクトリは標準パスと同じ意味を持ちます。

あなたが識別した問題のあるPIDファイルカイアサービスは/usr/local/var/runこんな感じです。

# (first stop whatever is using /usr/local/var/run)
# rm -Rf /usr/local/var/run
# ln -s /run /usr/local/var/run

私の考えでは、これが回避策であり、正しい解決策は修正することです。カイアサービススクリプトは完全修飾パスを使用します。ただし、このリンクを使用するのは安全な方法であり、問​​題を防ぐことができます。このパスを使用している他の人も恩恵を受けることができます。

ただし、/runrootが所有しているため、/usr/local/var/runこの回避策は使用されているサービスがrootとして実行されている場合にのみ機能します。そうでない場合は、接続することも/tmp別の回避策です。明らか次のような。

不揮発性PIDファイルが保存されている別の場所がある場合は、インストールの別の場所にこの回避策を適用する必要があります。

再構成

別のオプションは、正しいパスを使用するように適切なスクリプトを設定することです。通常、初期化スクリプトは次から始まります。基本ファイルの例/etc/default/kea： 。利用可能なオプションを見つけるには、サービスのマニュアルまたはスクリプトを参照する必要があります。

明らか

PIDファイルを作成するために専用アカウントを使用するサービス（例：ケアユーザー）そのアカウントのcronテーブルエントリを使用して起動時にPIDファイルを削除することで、PIDファイルの予想されるボラティリティをシミュレートできます。たとえば、

@reboot rm -f /usr/local/var/run/kea.pid

例は次のように編集されます# crontab -e -u kea-user。

おすすめ記事