☰

CentOS 7で私のsystemctlサービスが起動しない理由をどうやって知ることができますか？

tag-icon • tag-icon centos boot logs startup services
CentOS 7で私のsystemctlサービスが起動しない理由をどうやって知ることができますか？

CentOS 7を使用しています。サービスを開始できない理由はどうすればわかりますか？このサービスを作成しました

[rails@server ~]$ sudo cat /usr/lib/systemd/system/nodejs.service
[Unit]
Description=nodejs server

[Service]
User=rails
Group=rails
ExecStart=/home/rails/NodeJSserver/start.sh
ExecStop=/home/rails/NodeJSserver/stop.sh

[Install]
WantedBy=multi-user.target

文書には次の内容が記載されています。

[rails@server ~]$ cat /home/rails/NodeJSserver/start.sh
#!/bin/bash

forever start /home/rails/NodeJSserver/server.js

このファイルを直接実行できます。しかし、サービスの一部として実行しようとすると、NodeJSサーバーが起動しないことがわかりました。 「sudo systemctl --state=failed」を確認してもエラーは表示されません。

[rails@server ~]$ sudo systemctl enable NodeJSserver
[rails@server ~]$ sudo systemctl start NodeJSserver
[rails@server ~]$
[rails@server ~]$
[rails@server ~]$ forever list
info:    No forever processes running
[rails@server ~]$
[rails@server ~]$
[rails@server ~]$ sudo systemctl --state=failed
  UNIT                           LOAD   ACTIVE SUB    DESCRIPTION
● nginx.service                  loaded failed failed The nginx HTTP and reverse proxy server
● systemd-sysctl.service         loaded failed failed Apply Kernel Variables
● systemd-vconsole-setup.service loaded failed failed Setup Virtual Console

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

3 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

サービスが開始されない理由はどうすればわかりますか？

答え1

Type=あなたのサービスはそのセクションで指定されていないので、[Service]あなたsystemdが意味すると仮定しますType=simple。

つまり、開始されたプロセスはサービスの実行中にsystemd実行され続けます。しかし、1つのコマンドだけを実行してから終了するExecStart=ようです。start.shそれはforeverコマンド：forever startターゲットコマンドをデーモンとして実行します。つまり、バックグラウンドで実行します。コマンドが完了すると、forever start実行中のシェルがstart.sh終了します。

この時点では、systemdサービスが失敗したと見なされます。ただし、サービスに割り当てられた制御グループにはまだ実行中のプロセスがあります。 「だから、systemd失敗しただけでなく混乱を残しました。これはできません」と彼は考えました。何もKillMode=指定されていないKillSignal=ため、systemdデフォルト値を引き続き使用し、SIGTERM を残りのプロセスに送信します。そうでない場合、その制御グループが時間内に停止した場合、SIGKILLはその後送信されます。その後、実際のNodeJSプロセスが終了します。

それを修正する方法

実行したコマンドは、ExecStart=実際のサーバーが起動するとすぐに終了するため、デフォルトのType=simpleサービスタイプは使用できません。

Type=forkingこのタイプの場合は、オプションを使用することをお勧めしますman systemd.service。PIDFile=したがって、NodeJSサーバーが独自にPIDファイルを生成する場合（またはコマンドにオプションを追加してforeverPIDファイルを生成するようにする場合）、systemdこれを知らせる必要があります。どこにいますか？

[Service]
Type=forking
PIDFile=/absolute/path/to/nodejs.pid
User=rails
... <the rest as before>

それでも問題Type=forkingが解決しない場合。Type=oneshotRemainAfterExit=yes

systemdこれにより、サービスを開始および停止するときに他の操作を気にせずにコマンドのみを実行できます。ExecStart=ExecStop=

systemdただし、サービスが最後に停止状態に設定されたのか、開始状態に設定されたのかはまだ記憶されます。したがって、このサービスに依存するように他のサービスを設定してからNodeJSサービスを手動で停止すると、他のサービスは自動的に停止されず、NodeJSサービスが利用できない場合は間違いなくエラーが返されます。

3番目のオプションは、foreverコマンドを完全にスキップし、systemdNodeJSプロセスを再起動するタスクを実行することです。この場合、デバイスnodejs.service全体は次のようになります。

[Unit]
Description=nodejs server

[Service]
User=rails
Group=rails
ExecStart=/home/rails/NodeJSserver/server.js
Restart=always

[Install]
WantedBy=multi-user.target

他のオプションを追加できます。

たとえば、サービスが予期せず終了した場合にサービスを再開する前に待機時間を5秒に指定すると、何らかのRestartSec=5理由でサービスが再起動された直後にシャットダウンされた場合、頻繁な再起動の試行によってシステムリソースが消費されるのを防ぐことができます。 （デフォルトRestartSec=は100ミリ秒です。）

または、特定の終了ステータス値を返すときにサービスを再起動し、他の終了ステータス値が失敗することを検討している場合は、いくつかのオプションがあります。

関連情報