Linuxサーバーを再起動するには システムctlの再起動一見簡単そうに見える。コマンドを1つ、sudoパスワードを1つ入力するだけで、マシンが再起動する。問題は、この再起動によって、開いているセッション、SSH接続、実行中のプロセス、そして場合によっては誰かが使用していたサービスまでが閉じられてしまうことだ。
したがって、たとえ個人用マシンやVPSであっても、再起動は軽微なメンテナンス作業のように扱うことをお勧めします。目的は基本的なコマンドを複雑にすることではなく、実行中のプロセスを確認し、必要に応じて警告を表示し、後になって処理が進行中だったことに気づくことなく、クリーンに再起動することです。
systemctl reboot が実際に何をするのか
systemd を搭載した最新のディストリビューションでは、 システムctlの再起動 これはシステムにマシンの再起動を要求するもので、コマンドに似ています。 リブートしかし、あなたは明示的に システムドこれは、サービスの再起動前にサービスを停止させる処理を統括するものです。
sudo systemctl reboot混同しないでください systemctl poweroff機械の電源を切る、または systemctl haltハードウェアによっては、必ずしも電源を切断することなくシステムをシャットダウンします。カーネルの更新を適用したり、ネットワークスタックを再ロードしたり、起動時にサービスをチェックしたりするために再起動することが目的の場合は、 システムctlの再起動 これは直接的なコマンドです。
単にファイルを変更した場合 。サービス必ずしも完全な再起動が必要なわけではありません。その場合は、まず状況を理解することから始めましょう。 systemctl daemon-reload を使用するタイミングその後、問題となっているサービスのみを再起動してください。
ログアウトする前に開いているセッションを確認してください
サーバーを再起動する前に、まず誰が接続しているかを確認します。ばかげているように聞こえるかもしれませんが、同僚のセッションを誤って切断したり、SCP転送を中断したり、ターミナルから実行されたコマンドを妨害したりするのを防ぐためです。
誰が
w
loginctl list-sessions誰が 接続中のユーザーを一覧で確認できます。 w 彼らが何をしているかを付け加える。 loginctl list-sessions systemd システムでは特に、ローカルセッション、SSH セッション、グラフィカルセッションを識別したい場合に便利です。
本番サーバーでは、再起動前に警告を表示します。簡単なアナウンスで十分です。
sudo wall "サーバーはメンテナンスのため10分後に再起動します。"VPSを自分一人で使用している場合は、この手順は不要に思えるかもしれません。しかし、複数のアカウントが存在する場合、クライアントアクセスがある場合、長時間実行されるジョブがある場合、または公開されているアプリケーションがある場合は、常にこの手順を念頭に置いておくようにしています。
サービスと進行中のジョブを監視します。
クリーンな再起動だけではすべてが解決するわけではありません。再起動前にサービスに不具合が生じていた場合、再起動後も同じ状態に戻ってしまう可能性があります。事前に確認してから、再起動後に比較することをお勧めします。
systemctl --失敗
systemctl list-jobs
systemctl is-system-runningsystemctl --失敗 故障したユニットを一覧表示します。 systemctl list-jobs 保留中のsystemd操作を表示します。 systemctl is-system-running 全体的な状態を示します。 走っている、 劣化した または 起動。
重要なサービスに障害が発生した場合は、再起動する前にそのサービス名をメモしておいてください。
systemctl status サービス名
journalctl -u サービス名 -b --ページングなしより包括的なサービス一覧を取得し、アクティブなサービスと不具合のあるサービスを絞り込むには、以下のガイドも参照してください。 ランダムな再起動前に役立つsystemctlコマンドこれはまさに、原因と結果を混同することを避けるための検証方法である。
すぐにシャットダウンするのではなく、再起動を計画する
システムctlの再起動 すぐに再起動します。遅延を許可したい場合は、代わりにを使用してください。 シャットダウン オプション付き -r。ザ -r 再起動を意味します。
sudo shutdown -r +10 "10分後に再起動します"予定されている再起動をキャンセルするには：
sudo shutdown -c少しでも疑わしい点がある場合は、この方法を推奨します。バックアップを完了したり、セッションを閉じたり、ユーザーに通知したり、監視システムを確認したりするために、数分時間を確保できます。
のドキュメント シャットダウン 受け入れられている時間形式を理解したい場合に役立ちます。 システム制御systemd のリファレンスは、 公式systemctlページ。
SSHの場合：安全対策なしでは再起動しないでください
SSH で接続している場合、再起動するとセッションが切断されます。サーバーが正しく再起動すれば問題ありません。ネットワーク、ファイアウォール、ディスク、または SSH 上に戻ってはいけない。
- 可能であれば、コンソール、KVM、IPMI、iDRAC、iLO、またはベンダーコンソールへのアクセスを維持してください。
- マシンに既にエラーが表示されている場合は、再起動する前にディスクの空き容量を確認してください。
- テストされていないネットワーク変更後、すぐに再起動することは避けてください。
- ファイアウォールを変更した場合は、リターンルールまたはローカルルートセッションを維持してください。
VPSの場合、コマンドを実行する前にプロバイダのウェブコンソールが正常に動作しているかどうかも確認します。たった30秒で済み、面倒なサポート依頼を回避できます。
再起動後、マシンが正常に動作していることを確認してください。
再接続後、SSHが応答するからといって全てが正常だと決めつけないでください。まずは前回の起動状況を確認してください。
稼働時間
systemctl is-system-running
systemctl --失敗次に、現在の起動プロセス中にエラーがないか確認します。
journalctl -b -p warning..alert --no-pager前回の起動時と比較したい場合は、以下を使用してください。
journalctl -b -1 -p warning..alert --no-pagerへのガイド journalctlと最後のLinuxブート このセクションでは、起動が遅い、サービスが失敗した、またはハードウェアに関するメッセージを調査する必要があるかどうかについて詳しく説明します。
Linuxを再起動する前に私がチェックする項目
誰がまたはw公開セッションを見るには。systemctl --失敗既にエラーが発生しているサービスを特定する。systemctl list-jobs現在実行中のsystemd操作を中断しないようにするため。shutdown -r +10遅延を許容したい場合。- リモートワークの場合は、コンソールにアクセスできます。
journalctl -bエラーを確認するために再起動後。
テストステーションでは、 sudo systemctl reboot それで十分な場合が多い。サーバー上では、応答しないマシンを追いかけて10秒を稼ぐよりも、セッションやサービスを確認するのに2分かける方がずっと良い。