web-dev-qa-db-ja.com

ハードリスタート後に古いpidfileの問題を回避すると、デーモンが強制終了します

（VMWare）VMでRed Hat Linux（RHEL5）を使用しています。常に実行され続け、起動時に自動的に実行されるデーモンを作成しました。

昨夜、VMホストに回復不能なハードウェアの問題があり、VMが突然停止しました。戻ったとき、pidfileがまだ存在していたため、デーモンが起動しませんでした。 。

どうやらこれは The Stale pidfile Syndrome と呼ばれていますが、それを軽減するための最良の長期的アプローチが何であるかはわかりません。 /etc/rc.d*の起動スクリプトはデーモンを起動する前にpidfileを削除する必要があると思いますが、/etc/init.dのサービス管理スクリプトは同じままにして、service mydaemon startのようなものが壊れることがないようにする必要がありますpidfile。

/etc/rc.d/rc6.dには/etc/init.d/のスクリプトへのシンボリックリンクがあるだけなので、起動時のみの動作を変更するにはどうすればよいですか？ rc.d dirsで優先順位の高い追加のスクリプトを作成できますが、ハッキーのようです。 「uptimeが1分未満の場合は、pidfileを削除する」などのロジックを追加することも提案されましたが、これもハッキーのようです。

考えや解決策、またはベストプラクティスはありますか？

linuxbootdaemon
4
Nathan

daemontools を使用し、 Process Management を参照してください。

3
Paused until further notice.

@Dennisと@coredumpのヒントをありがとうございます。

謎を解き明かすのに役立ついくつかの追加情報を見つけました。

  1. なぜ他のすべてのデーモンが正常に回復したのか疑問に思いました。起動時に/etc/rc.d/rc.sysinitと/var/runのすべてのpidfileをクリーンアップするコードが/var/lockにあることがわかりました。

  2. SELinuxで問題が発生し、「誤ってラベル付けされた可能性のあるファイルを使用」できなくなったため、pidfileを別の場所に配置するようにデーモンを構成しました。

したがって、SELinuxの問題のためにまだ修正していませんが、答えは"pidfileを/var/runまたは/var/lockに入れれば、次回は機能します"

2
Nathan

スクリプトは同じです。起動プロセスは、sysvinitスクリプトに対して「start」アクションを実行するだけです。

Pidファイルのpidが正しいかどうかを確認し、削除せずに正しいpidで新しいpidを作成してみませんか？

[〜＃〜] edit [〜＃〜]：pidfileを使用してpsをgrepして、プロセスがまだ存在するかどうかを確認できます。または、その逆を行います。 RedHat initscriptsを確認してください。これを行うには、pidofprocなどのヘルパー関数がいくつかあると思います。

1
coredump