失敗したサービスは、即座に再起動する必要はありません。サーバー上では、この習慣が時折、障害を説明するメッセージを消去したり、常に無効な設定でプログラムを再起動させたりします。
まず、関連するユニットを特定し、その状態とログを確認し、原因を修正します。再起動はその後に行います。
実際に失敗しているユニットをリストアップする
このコマンドは、systemdが失敗と見なすサービスとユニットを表示します：
systemctl --failed完全な名前をメモしてください。例えば、nginx.serviceやmon-application.serviceなど。exitedのユニットは必ずしも故障しているわけではありません：いくつかのサービスは短いタスクを実行した後、正常に停止します。failedのステータスは、起動、制御コマンド、または監視プロセスがエラーで終了したことを示します。
アクティブ、停止中のサービスとその状態を見直すには、systemctlによるサービスのリストもご覧ください。
再起動前にサービスの状態を確認する
nginxをあなたのユニットに置き換えます。--no-pagerオプションは、結果を直接ターミナルに印刷し、SSHセッション内でlessにとどまるのを防ぎます。
sudo systemctl status nginx --no-pager特にActive:行、終了コード、表示された最後の行を見てください。すでに使用されているポート、欠落しているパス、読み取れない証明書、またはスペルミスのあるディレクティブがよくここに表示されます。サービスが独自のバリデーターを持つバイナリを起動する場合は、まずそのバリデーターを実行してください。例えば、Nginxの場合：
sudo nginx -tNginxを使用していないマシンでこのコマンドを実行しないでください。各サービスには検証の文法があります。
journalctlでエラーメッセージを確認する
systemctl statusは抜粋しか表示しません。ユニットのログは完全なコンテキストを提供します：
sudo journalctl -u nginx -b --no-pager
sudo journalctl -u nginx -n 50 --no-pager-bは現在の起動に検索を制限します。-n 50は故障が古い場合、最後の50行を保持します。リアルタイムで再起動を追跡するには、別のSSHセッションでsudo journalctl -fu nginxを使用してください。journalctlと最後の起動メッセージガイドは、複数のサービスに影響するエラーの診断を広げるのに役立ちます。
修正し、再起動後に確認する
ユニットファイルやsystemdのドロップインに変更を加えた後、設定を再読み込みします。このステップはサービスを再起動しません。
sudo systemctl daemon-reload
sudo systemctl restart nginx
systemctl is-active nginx
systemctl --failedis-activeはactiveと返答するべきです。サービスがポートで待機している場合は、そのポートも確認し、正しいクライアントからテストを行ってください。activeの応答は、ウェブアプリケーション、プロキシ、またはデータベースがすでにリクエストを受け付けていることを保証するものではありません。
重要なサービスの場合、再起動前に別のSSHセッションを開き、チケットやメモに正確なエラーメッセージをコピーしてください。次回のインシデントの際に同じ診断を繰り返すのを避けることができます。