☰

追加読書

tag-icon • tag-icon shell ubuntu systemd java
追加読書

systemdフォークされたサービスに基づく起動スクリプトがあります。fooYAJSW（別のJavaサービスラッパー）。文書の関連部分は.service次のとおりです。

ExecStart=/opt/foo/startup.sh
ExecStop=/opt/foo/shutdown.sh
Restart=always    
Type=forking
PIDFile=/opt/foo/wrapper.pid

このstartup.shスクリプトはYAJSWラッパーの起動を担当します。起動時に対応するPIDがファイルに書き込まれるようにYAJSW設定ファイルを設定します。

 wrapper.pidfile = /opt/foo/wrapper.pid

これにより（何らかの理由で）ラッパープロセスが終了したら、systemdはこれを開始する必要があります。これは望ましい動作です。この設定が正しく機能していることを確認しましたが、Journalctlに奇妙な行が表示されます。

foo.service: PID file /opt/foo/wrapper.pid not readable (yet?) after start: No such file or directory

奇妙なことに、systemctl status fooはマスターPIDを正しく表示します。

foo.service
...
Main PID: 12313 (java)

私が何か間違っているのか、それともソフトウェアコンポーネントの1つのバグですか？私はUbuntu 16.04.3 LTS、カーネルバージョン4.4.0、システムバージョン229.4を実行しています。どんな助けでも大変感謝します。

答え1

フォークされたサービス[...] YAJSW（別のJavaサービスラッパー）[...] ExecStart=/opt/foo/startup.sh[...] ExecStop=/opt/foo/shutdown.sh[...] PIDがファイルに書き込まれます[...]

この種のタスクはJavaでよく見られ、通常はOracleシステムでもよく見られるように見えますが、まったく必要ありません。実際のサービスマネージャで実行するためにシェルスクリプトやJavaで書かれたPoor Man Service Managerは必要ありません。 PIDファイルは完全に危険で不安定なメカニズムです。startup.shスクリプトは不要で、shutdown.sh最終的には良い結果なしにプロセスツリーの上に実際のサービスプロセスをプッシュします。追加の YAJSW 構成ファイルは必要ありません。メモリの標準出力バッファリングに基づく複雑で特別なロギングメカニズムは必要ありません。

あなたのサービスプロセスは実際のサービス管理によって直接管理されなければならず、ほとんど何もないので、システム化されたフォーク準備プロトコルを使用しません。実際にそれを書いてください。 Poor Man's Service Managerを実行するためにラッパーシェルスクリプトを使用しないでください。 PIDファイルを使用しないでください。すべてのシェルスクリプトラッパーはフォークではなくチェーンロードする必要があります。構成ファイルは、一部ではなくシステム・サービス単位ファイルです。その他構成ファイル。ロギングメカニズムは、標準出力と標準エラーをキャプチャし、そのデータをファイルに書き込むサービス管理に付属するメカニズムです。

追加読書

答え2

私はこれがバグではなく複雑さの問題だと言いたいです。現在、アプリケーションを起動して管理するためのチェーンがあります。

systemd -> startup.sh -> YAJSW -> actual app

私はstart.shとYAJSWが正確に何をしているのかわかりませんが、管理を簡素化する方が良いでしょう。

systemd -> actual app

だから管理に問題があればたくさん何が起こったのかを推測する方が簡単です。

管理ツールの使用を最大化systemdし、スクリプトとYAJSWが実行する作業を最小限に抑えるか削除することで、状況を簡素化することをお勧めします。

関連情報