systemdのサービスが起動しないときの確認方法｜status・journalctlで原因を調べる
Linuxサーバーでは、NginxやDocker、アプリケーションなどのサービスをsystemdで管理することがあります。
ところが、systemctl startを実行してもサービスが起動しなかったり、起動してもすぐ停止したりすることがあります。
このような場合は、何度も再起動を繰り返すより、systemctl status → journalctl → 設定ファイル → 実行ファイル・権限の順番で確認すると原因を見つけやすくなります。
systemdとは？
systemdは、Linuxの起動時にサービスを開始したり、サービスの状態を管理したりする仕組みです。
例えばNginxの状態を確認する場合は、
sudo systemctl status nginx
サービスを起動する場合は、
sudo systemctl start nginx
再起動する場合は、
sudo systemctl restart nginx
というようにsystemctlコマンドを使います。
まずsystemctl statusを確認する
サービスが起動しないときは、最初に状態を確認します。
例えば、
sudo systemctl status nginx
を実行します。
正常に動作している場合は、
Active: active (running)
のように表示されます。
起動に失敗している場合は、
Active: failed
などと表示されます。
ここにはサービスの状態だけでなく、直前に実行されたコマンドやエラーメッセージが表示されることがあります。
そのため、まずstatusの結果を確認することが重要です。
サービスを手動で起動してみる
サービスが停止している場合は、手動で起動します。
sudo systemctl start nginx
起動後に、
sudo systemctl status nginx
を実行します。
ここでactive (running)になれば起動できています。
一方、failedになった場合は、ログを確認します。
journalctlでエラーを確認する
systemdが管理するサービスのログはjournalctlで確認できます。
例えばNginxの場合は、
sudo journalctl -u nginx
でログを確認できます。
直近のログだけ確認したい場合は、
sudo journalctl -u nginx -n 100
とします。
直近30分のログに絞るなら、
sudo journalctl -u nginx --since "30 minutes ago"
も便利です。
サービス名を自分の環境に合わせて変更してください。
エラーメッセージを確認する
ログには、サービスが起動できなかった理由が表示されることがあります。
例えば、
- ファイルが存在しない
- ポートがすでに使用されている
- 権限がない
- 設定ファイルに問題がある
- 実行ファイルが存在しない
- 環境変数が不足している
などです。
エラーが表示されている場合は、その内容を確認してから原因になっている設定を調べます。
単純にrestartを繰り返すだけでは原因は解決しません。
サービスの設定ファイルを確認する
systemdサービスの設定を確認したい場合は、
systemctl cat nginx
のように実行できます。
サービスのUnitファイルにどのような設定があるのか確認できます。
より詳細な状態を確認する場合は、
systemctl show nginx
も利用できます。
ただし、設定ファイルを直接編集する前に、現在どのような設定が読み込まれているのかを確認することが大切です。
ExecStartの設定を確認する
systemdサービスでは、ExecStartに起動するプログラムが指定されていることがあります。
例えば、
[Service]
ExecStart=/usr/local/bin/myapp
となっている場合、/usr/local/bin/myappが存在しなければサービスを起動できません。
ファイルが存在するか確認します。
ls -l /usr/local/bin/myapp
実行権限も確認できます。
ls -l /usr/local/bin/myapp
先頭付近にxが含まれているか確認してください。
実行ユーザーと権限を確認する
Unitファイルに、
[Service]
User=myapp
のような設定がある場合、サービスはmyappユーザーとして実行されます。
そのユーザーに必要なファイルやディレクトリへのアクセス権がなければ、起動に失敗することがあります。
ファイルの権限は、
ls -l ファイル名
ディレクトリの権限は、
ls -ld ディレクトリ名
で確認できます。
rootで手動実行すると正常なのにsystemdでは失敗する場合、実行ユーザーや環境変数が原因になっていることがあります。
ポートがすでに使用されていないか確認する
サービスがポートを使用する場合、同じポートを別のプロセスが使っていると起動できないことがあります。
例えば80番ポートを確認するなら、
sudo ss -lntp | grep :80
とします。
アプリケーションが3000番ポートを使用している場合は、
sudo ss -lntp | grep :3000
です。
「Address already in use」のようなエラーがログに出ている場合は、ポートの重複を確認しましょう。
設定ファイルに問題がないか確認する
サービスによっては、起動時に設定ファイルを読み込みます。
設定ファイルに構文エラーがあると、サービスが起動できない場合があります。
例えばNginxなら、
sudo nginx -t
で設定を確認できます。
このように、systemdだけでなくサービス本体が提供している設定チェックコマンドも確認すると原因を切り分けやすくなります。
Unitファイルを変更した場合はdaemon-reloadを使う
systemdのUnitファイルを変更した場合は、設定を再読み込みする必要があります。
sudo systemctl daemon-reload
その後、サービスを再起動します。
sudo systemctl restart myapp
daemon-reloadは、Unitファイルを変更したときに使うコマンドです。
サービスを再起動するだけでは、変更したUnitファイルが期待どおり反映されない場合があります。
サービスが起動後すぐ停止する場合
「起動できない」のではなく、起動した直後に停止するケースもあります。
例えば、
sudo systemctl start myapp
を実行した直後はエラーが出なくても、
sudo systemctl status myapp
を見ると、
Active: failed
になっていることがあります。
この場合は、
sudo journalctl -u myapp -n 100
でサービスが停止した直前のログを確認します。
アプリケーション自体がエラーで終了している可能性もあるため、アプリケーションのログも確認してください。
自動起動の設定を確認する
サーバーを再起動したあとにサービスが起動しない場合は、自動起動が有効になっているか確認します。
sudo systemctl is-enabled nginx
enabledと表示されれば、自動起動が有効です。
有効になっていない場合は、
sudo systemctl enable nginx
で有効化できます。
ただし、サービスが正常に起動できることを確認してから自動起動を設定するほうが安全です。
systemdサービスのトラブルを調べるコマンド
よく使うコマンドをまとめると、次のようになります。
| 確認内容 | コマンド |
|---|---|
| サービス状態 | systemctl status サービス名 |
| サービス起動 | systemctl start サービス名 |
| サービス停止 | systemctl stop サービス名 |
| サービス再起動 | systemctl restart サービス名 |
| ログ確認 | journalctl -u サービス名 |
| 最新ログ | journalctl -u サービス名 -n 100 |
| Unitファイル確認 | systemctl cat サービス名 |
| 自動起動確認 | systemctl is-enabled サービス名 |
| Unit設定再読み込み | systemctl daemon-reload |
| ポート確認 | ss -lntp |
systemdのトラブルでやってはいけないこと
原因を確認せず何度もrestartしない
サービスが起動しないときに、
sudo systemctl restart myapp
を何度も繰り返しても、設定ミスや権限エラーが自動的に解決するわけではありません。
まずstatusとjournalctlを確認しましょう。
Unitファイルをいきなり直接変更しない
パッケージで管理されているサービスのUnitファイルを直接編集すると、アップデート時に変更が失われる可能性があります。
独自サービスなどでは、環境に合わせたUnitファイルの管理方法を確認してください。
chmod 777で解決しようとしない
権限エラーが出たからといって、ファイルやディレクトリを無条件に777へ変更するのは避けましょう。
まず、どのユーザーでサービスが実行されているのかを確認し、そのユーザーに必要な権限だけを与えることが重要です。
まとめ
systemdのサービスが起動しないときは、最初から設定を変更するのではなく、原因を順番に切り分けることが大切です。
まず、
systemctl status → journalctl → Unit設定 → ExecStart → 権限 → ポート → サービス本体の設定
という流れで確認してみましょう。
特にsystemctl statusだけで原因が分からない場合は、journalctlでサービスが失敗した直前のログを確認すると、原因を絞り込みやすくなります。
また、Unitファイルを変更した場合はsystemctl daemon-reloadが必要になることがあります。
サービスを何度も再起動するより、ログを確認しながら一つずつ原因を切り分けることが、Linuxサーバーのトラブル対応では重要です。
systemdのサービスが起動しないときは最初に何を確認すればいいですか？
まずsystemctl status サービス名を実行してください。
サービスの状態や直前のエラーが表示されます。さらに詳しい原因を調べる場合はjournalctl -u サービス名でログを確認します。
systemctl statusでfailedと表示された場合はどうすればいいですか？
journalctl -u サービス名 -n 100などでログを確認し、設定ファイル、実行ファイル、権限、ポートなどを順番に調べます。
Unitファイルを変更したのに設定が反映されません
Unitファイルを変更した場合は、
sudo systemctl daemon-reload
を実行してからサービスを再起動してください。
サービスは起動するのにすぐ停止するのはなぜですか？
サービス本体がエラーによって終了している可能性があります。
journalctlで停止直前のログを確認し、アプリケーション側のログも合わせて調べると原因を切り分けやすくなります。
Linuxのポートが開いているか確認する方法｜ss・nc・curlで接続障害を切り分ける
Nginxで502 Bad Gatewayが出たときの原因と解決方法｜確認する順番を解説
Dockerコンテナが起動しないときの確認方法｜docker ps・logsで原因を調べる手順