web-dev-qa-db-ja.com

RHEL7でのsystemd移行へのSysVinitスクリプト

Linuxの（ユーザープロセス）エージェントおよびセキュリティデーモンのSys VInitスクリプトを見つけてください。

  1. エージェントデーモン起動スクリプト/etc/rc.d/init.d/Agentdaemon/etc/rc.d/rc5.d/S91Agentdaemon

  2. セキュリティデーモン起動スクリプト/etc/rc.d/init.d/Securitydaemon/etc/rc.d/rc5.d/S91Securitydaemon

エージェントデーモンとセキュリティデーモンの両方に、共通の親、つまり共通のエージェントが必要であると仮定します。再起動時に共通エージェントが起動されていない場合、他のデーモンはいずれも共通エージェントを起動し、他のデーモンはスキップして共通エージェントを起動します。共通エージェントが実行されているかどうかを確認するための「ps」コマンドチェックがあり、AgentdaemonスクリプトとSecuritydaemonスクリプトの両方で作成をスキップします。これはRHEL6.2で正常に機能しました。しかし、RHEL 7では、2つの一般的なエージェントが実行されています。

また、systemdがエージェントとセキュリティデーモンの両方を並行して開始したことも疑わしいです。どういうわけか、「ps」は実行中の共通エージェントを示していません。

例：ps -ef | grep共通| grep -v grep | awk '{print $ 2}'は、他のスクリプトによって開始された共通プロセスを表示していないため、他のスクリプトも共通エージェントを開始します。

起動スクリプトが並列で実行されないようにする方法はありますか、またはスクリプトをsystemd形式に移行する必要がありますか？迅速な回避策は、すべてのスクリプトをSys Vinitタイプからsystemdに移行するよりも重要です。

linuxrhelsystemdsysvinit
1
Srikanth Ganesan

スクリプトをsystemd形式に移行する必要がありますか？

はい。

System 5 rcスクリプトのよく知られた欠陥に悩まされています。 systemdとは何の関係もありません。たとえばstartparなど、他の方法でスクリプトを並行して起動できた場合は、この問題が発生した可能性があります。

psの出力をgrepすることは、grepと進行中のシステム状態の両方に対して競合する傾向があることはよく知られており、decades異なるシェルスクリプトでこれらの同じ障害を何度も何度も打つと報告している人々の。それは巧妙で間違った方向に進んでおり、psのBSDマニュアルページの「バグ」セクションで言及されています。世界は今ではもっとよく知っているはずです。

世界はもっとよく知っており、しばらくの間持っています。 1990年代の初めから、プロセスリストと、正しい番号が含まれている場合と含まれていない場合があるファイルのgrepを含む、これらのまとめられたメカニズムのすべてがなくても、適切に機能するサービスマネージャーがありました。この競合状態や他の競合状態に見舞われている場合は、間違いなく、これらの厄介で失敗しやすい、特異で厄介なシステム5を投げる必要がありますrcスクリプトを削除し、適切なサービス管理を使用します。 ifsはありません。ノーバット;すでに使用しているボッジに「迅速な回避策」のボッジはありません（余分なgreps自体が最初のボッジです）。

利用可能なそのようなサービスマネージャーはたくさんあります。 systemdを使用する必要はありません。 runit、nosh、またはperp用に作成するさまざまなスクリプトは、systemd用に作成するユニットファイルと同じくらい単純です。

物事を行うためのnoshおよびsystemdの方法では、2つのプライマリサービスがセカンダリサービスをチェックして実行する必要はありません。それがサービス管理システムの仕事です。むしろ、単に2つのプライマリサービスからセカンダリサービスへの依存関係を宣言するので、サービス管理システムは、開始するように指示されたときにそれを認識しますAgentdaemon.serviceおよびSecuritydaemon.service開始する必要がありますcommon.service 同様に。 systemdサービスユニットでは、これはRequires=またはWants=設定。

参考文献

2
JdeBP