Linuxサービスを再起動する前に、実際に何が実行されているかを確認するのが私の好みです。 システムド、 システム制御 既に必要な機能はほぼ全て揃っています。稼働中のサービス、障害が発生したサービス、自動起動、詳細なステータス、最新の役立つメッセージなどです。
これは特にサーバーで当てはまります。再起動 nginx、 ssh、 マリアドブ ビジネスサービスは、ステータスを確認せずに実行すると、セッションを終了させたり、Webサイトを中断させたり、設定エラーを隠蔽したりする可能性があります。Linuxサービスを適切に一覧表示し、重要なサービスをフィルタリングし、再起動が本当に必要かどうかを判断するために必要なコマンドを以下に示します。
systemctlでアクティブなサービスを一覧表示します
最も直接的なコマンドは、現在ロードされているサービスタイプのユニットを表示することです。
systemctl list-units --type=service複数の列を持つリストが表示されます。最も重要な列は次のとおりです。 負荷、 アクティブ、 サブ そして 説明実際には、私は主に アクティブ そして サブ サービスはロードされる可能性がありますが、エラーによって停止したり、通常の動作として終了したりすることがあります。
現在実行中のサービスのみを表示するには：
systemctl list-units --type=service --state=running停止中のサービスを表示するには：
systemctl list-units --type=service --state=exitedサービスが表示されてもパニックにならないでください 終了しました一部のプロセスは、短時間の動作を開始した後、正常に停止します。問題があると結論付ける前に、該当するサービスを調査する必要があります。
失敗したサービスを表示する
機械に不具合が生じた場合は、まず以下のコマンドを実行してください。
systemctl --失敗これは、systemdが障害と判断したユニットを表示します。これは、何も考えずに再起動するよりも便利です。なぜなら、検査すべきサービスの正確な名前がすぐにわかるからです。
例 ：
systemctl status sshまたは、分布に応じて：
systemctl status sshd出力には、サービスの状態、使用されているユニットファイル、サービスが実行中の場合はプライマリPID、および最後の数行のログが表示されます。起動失敗の原因を診断する必要がある場合、これらの数行が最初の手がかりとなることがよくあります。
サービスが自動的に開始するかどうかを判定する
サービスは、起動時に有効化されなくても、現在アクティブな状態になっている場合があります。その逆もまた同様です。サービスは有効化されていても、障害が発生したり、まだ起動されていないために停止している場合があります。
起動時のユニットファイルとその状態を一覧表示するには：
systemctl list-unit-files --type=service最も一般的な州は次のとおりです。
有効サービスは自動的に起動するように設計されています。無効自動的には起動しません。静的: 直接起動されるのではなく、他のユニットから呼び出すことができます。マスクされたサービスは意図的にブロックされています。
特定のサービスを確認するには：
systemctl is-enabled nginx
systemctl is-active nginx最初のコマンドは自動起動に関する応答です。2番目のコマンドは現在の状態に関する応答です。どちらの情報も、… システム制御ステータスしかし、それらは制御スクリプトや簡単なチェックリストでは便利です。
リストを絞り込むが、迷子にならないようにする
サーバーがやや混雑している場合、完全なリストはすぐに長くなります。フィルターするには、 grep 一連のサービスをお探しの場合：
systemctl list-units --type=service | grep sshページャーなしでアクティブなサービスのみを表示するには：
systemctl list-units --type=service --state=running --no-pagerチケットや簡単な診断でより読みやすい出力が必要な場合は、次の手順に従ってください。
systemctl list-units --type=service --state=failed --no-pagerリモートサーバーでは、よく追加します --ページングなしこれにより、特にSSH経由で迅速に作業している場合に、対話型ディスプレイでフリーズしてしまうことを防ぐことができます。
再起動する前にログを確認してください
サービスでエラーが発生している場合は、 再起動まず、新聞を見てみましょう。
journalctl -u nginx -n 50 --no-pagerライブログを確認するには：
journalctl -u nginx -fここでは、ポートが既に使用されている、設定ファイルが無効、権限が間違っている、依存関係が不足しているなどのエラーが表示されることがよくあります。systemdのログを初めて使用する方のために、詳細な説明も記載しています。 journalctlを使用して、前回のLinux起動時のログを読み取る方法。
チェックが完了してから再起動してください。
サービスが特定されたら、ツールが許可する範囲でその設定を確認します。例えば、Nginxの場合は次のようになります。
nginx -tSSHの場合は、さらに注意が必要です。誤ったサービスを再起動したり、設定が無効だったりすると、リモートアクセスを失う可能性があります。セッションを開いたままにして、ファイアウォールを確認してから、SSHを使用してください。 リロード それで十分な時。
sudo systemctl reload ssh
sudo systemctl restart ssh注文 リロード サービスが完全に停止せずに設定を再読み込みするようにサービスに要求します。ただし、サービスがそれをサポートしている場合に限ります。 再起動 サービスが中断され、その後再開される。これは同じレベルのリスクではない。
systemdユニットファイルを変更した場合は、以下の違いも考慮してください。 デーモンリロードこの件については、記事の中で別途説明しました。 Systemctl daemon-reloadは、Linux環境で実際にいつ使用すべきでしょうか？。
サービスを受ける前に確認すべきミニチェックリスト
- 関連するサービスをリストアップしてください
systemctl list-units --type=service。 - 次のコマンドでエラーを確認します
systemctl --失敗。 - 正確なステータスを確認するには
systemctl status サービス名。 - ログを確認するには
journalctl -u サービス名。 - サービスに検証コマンドがある場合は、設定をテストしてください。
- 好む
リロードもっている再起動それが許容され、かつ十分な場合。
のドキュメント システム制御 詳細なオプションが記載されていますが、日常的な使用においては、これらのコマンドでほとんどの診断は既に網羅されています。私の助言としては、サービスを再起動する理由がわからない場合は、すぐに再起動しないでください。問題点をリストアップし、ログを確認してから、適切な対応を取ってください。