私たちのアプリケーションはinit.dスクリプトを使用してアプリケーションをサービスとして起動および停止します。 CentOS 7では/sbin/init
シンボリックリンクはsystemdなので、次のいずれかを使用してアプリケーションを起動できます。
service myapp start
または
systemctl start myapp
私が経験している問題は、サービスを使用したりstop
サービスを実行してもアプリケーションが停止しないことです。出力:service
systemctl
systemctl 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でリッスンするデータベースサーバーである場合、最初のルールはほぼ確実に適用されます。