systemdはサービスが停止したかどうかを判断しますか?

systemdはサービスが停止したかどうかを判断しますか?

私たちのアプリケーションはinit.dスクリプトを使用してアプリケーションをサービスとして起動および停止します。 CentOS 7では/sbin/initシンボリックリンクはsystemdなので、次のいずれかを使用してアプリケーションを起動できます。

service myapp start

または

systemctl start myapp

私が経験している問題は、サービスを使用したりstopサービスを実行してもアプリケーションが停止しないことです。出力:servicesystemctlsystemctl status

[root@nec04 ~]# systemctl status myapp
myapp.service - SYSV: Service script to start/stop my application
   Loaded: loaded (/etc/rc.d/init.d/myapp)
   Active: inactive (dead) since Mon 2015-10-05 15:17:41 CEST; 22h ago
  Process: 31850 ExecStop=/etc/rc.d/init.d/myapp stop (code=exited, status=0/SUCCESS)
  Process: 21054 ExecStart=/etc/rc.d/init.d/myapp start (code=exited, status=0/SUCCESS)

使用serviceコマンド:

[root@nec04 ~]# service myapp status
Local database at :3307 is started
Watchdog is running
Application is running

私のアプリケーションがなぜsystemctl実行されないと思いますか?私のアプリケーションが停止したと思ったので、systemctlは停止機能を呼び出しませんでしたか?

答え1

出力がわからず、service実際にツールを使用したことはありませんが、systemctlアプリケーションによっては停止しました。これがこのActive: inactive (dead)行が意味するものです。 (Loaded単にsystemdがユニットファイルをメモリにロードしたということです。これはアプリケーションが実行されているかどうかにかかわらず常にそうです。)

アプリケーションに実際にまだ実行中のプロセスがある場合、これは停止機能が正しく機能しないことを意味します。しかし、これは起こってはいけません。何かsystemctlが停止したら(タイムアウト後)、cgroupを使用してそのアプリケーションで起動されたすべてのプロセスを強制終了します。したがって、プロセスがrootとして実行され、意図的にcgroupを離れない限り(非常に病理的な動作)、systemdはそれを終了する必要があります。しかし、sysVinitエミュレーションとどのようにやり取りするのかわかりません。

全体的な問題は、sysVinitエミュレーションを使用するsystemdがinitスクリプトをユニットファイルとして使用するという事実によって複雑になります。前述のように、適切な単位ファイルに書き直す方が良いかもしれません。ここType=simpleプログラムがdbusと会話するよりもスイッチやそれに対応する機能を持つ方が一般的で制御可能なType=dbusコードに追加する方が簡単なので、代わりに使用することをお勧めします。--no-daemon

答え2

私のアプリケーションがなぜsystemctl実行されないと思いますか?

トムハンターが言ったように実行されなかったからです。

systemctl私のアプリケーションが停止していると思って停止機能を呼び出さないからですか?

いいえ、非常に明確にした停止機能を呼び出し、プロセス#31850として実行します。

これには2つの可能性があり、どちらもシステムの問題ではありません。

  • ある時点では、システムサービスではなくサービスプログラムを直接起動します。それがまだ実行されているのです。もちろん、systemdはこれを知りません。
  • statusスクリプト機能に問題がありますinit.d。これはinit.d世界史上初めて欠陥のある台本ではありません。

myapp.service - SYSV:私のアプリのサービスの起動/停止スクリプト

「sysv:」に賞品があることは、あなたのinit.dスクリプトが悪いことを示しています。 LSBヘッダブロックもありません。

Tom Hunterが言ったように、いくつかのサービスユニットを作成します。または、systemdに移行する最初のルールを覚えてから、すでに作成されたルールを調整します。表面的には、実際には3つの相互依存性がありますが、異なるサービスがあり、これらの相互依存性を表現するには、複数のサービス単位を作成する必要があります。そのうちの1つがポート3307でリッスンするデータベースサーバーである場合、最初のルールはほぼ確実に適用されます。

追加読書

関連情報