再起動はいつ必要ですか？

カーネルのアップグレードとは別に、Linuxシステムに再起動が必要な変更がありますか？再起動により状況が簡単になる状況はありますが、再起動しない限り達成できない状況はありますか？

明確にするために：ハードウェアの誤動作に悩まされていない典型的なデスクトップまたはサーバーシステムを考えています。

linux reboot

— マーク
ソース

再起動せずにすべてのことができます。カーネルの変更でさえkspliceを使用して実行できるため、カーネルをホットスワップできます。あなたが考慮に入れる必要がある唯一のものは、再起動せずに事実作るすべてが非常に複雑になる可能性がある

— Kiwy

「Linuxシステム」は多くの非常に異なることを意味するため、あなたの質問は非常に広範囲です。

— ズリン14

また、「変更」とは、非常に多くの異なる状況を意味します。MDミラーの一部である故障したハードドライブからの回復は、このような変更ですか？「はい」の場合-残念ながら-たとえば、一部のHDD障害（一部のHDDコントローラー）によりシステムが応答しなくなるため、再起動が必要になる場合があります。しかし、あなたはおそらく、このような「変化」...について尋ねていません

— Zrin

@Kiwy技術的には、kspliceはカーネルを変更しません。Kspliceを使用すると、実行中のカーネルに実行中のパッチを適用できます。kexecのことを考えているかもしれません。これにより、メモリ内の実行中のカーネルに「新しい」カーネルイメージをロードできます。

— トーマスナイマン14

これは、Windowsのインストール以降4年間開かれていなかったIE8（または任意の数）を更新しただけでも、Windows XP（私は超えたことがありません）が再起動についてシャットダウンしないことを思い出させます。ブラウザ。

— シャーバズ14

回答:

いくつかのことが思い浮かびます。

カーネルパニックから回復する

カーネルパニックは、定義上、カーネルを再起動しないと回復できません。
端末にアクセスできなくなるハングから回復する

システムが応答せず、回復するためのコマンドを発行する方法がないまま立ち往生している場合、できることはリブートすることだけです。通常、手動での電源の再投入は避けたいでしょう。このような状況では、LinuxカーネルはMagic SysRqをサポートしており、緊急時にマシンを再起動するために使用できます。

CONFIG_MAGIC_SYSRQカーネル構成でkernel.sysrq sysctlオプションが有効になっており、オプションが有効になっている限り、魔法のSysRqキーの組み合わせを使用して、コマンドをカーネルに直接発行できます。

以下のAlt+ SysRqは、を押し続け Alt、次に押し 続けることを意味することに注意してくださいSysRq（通常はPrintScrnキー）。
1. Alt+ SysRq+ r：キーボードの制御を取り戻す
2. Alt+ SysRq+ e：SIGTERMを除くすべてのプロセスに送信し、init正常に終了する機会を与えます
3. Alt+ SysRq+ i：SIGKILLを除くすべてのプロセスに送信しinit、強制的に終了させます
4. Alt+ SysRq+ s：マウントされたすべてのファイルシステムの同期を試みます
5. Alt+ SysRq+ u：すべてのファイルシステムを読み取り専用で再マウントします
6. Alt+ SysRq+ b：再起動、または
  
  Alt+ SysRq+ o：シャットダウン
グレースフルリブートを試行するためのマジックSysRqキーの組み合わせのニーモニックは次のとおりです。

" R EBOOT E VEN I F S ystem U tterly Bのroke "

ヘッドレスサーバーの場合、ネットワーク上でリモートSysRqシーケンスを有効にするiptablesターゲットもあります。
起動できない状態から回復する

システムがすでに通常のブートが不可能な状態になっている場合（たとえば、システムアップグレードの失敗、ファイルシステムの破損など）、システムの回復コンソールにアクセスする唯一の方法は再起動することです適切な起動時オプションを使用します。
起動時のカーネルパラメータを変更する

一部のカーネルパラメーター（auditカーネル監査の有効化/無効化など）は、ブート時にカーネルが読み込まれるときにのみ設定できます。

— トーマス・ナイマン
ソース

「システムが完全に壊れたとしても再起動する」私は念のためこの質問に賛成しているが、私はそれを決して忘れないとは思わない。

— embedded.kyle 14

kexecを使用してパニックから抜け出し、完全な再起動を回避できることに注意してください。これは、起動不可能な状態ポイントからの脱出にも同様に適用されます。（少なくともx86システムでは、これらは決して同じものではありません）。ただし、この回答の残りの部分については+1。

— バリティ14

@Valityコメントありがとうございます。kexecが再起動を必要とする場合、おそらくある程度は1つの観点に依存します。たとえば、kdumpのドキュメントでは、システムカーネルのメモリイメージを保持するリブートとしてkexec-on-panicについて説明しています。起動不可能な状態に関するポイントについては、ブートローダーの誤設定（たとえば、最初にカーネルをロードできないなど）も考慮しましたが、kexecは役に立ちません。質問の性質を考えると、セマンティクスに関する意見の違いは避けられないと思います。

— トーマスナイマン14

@ThomasNymanあなたが正しいと思う質問を見て、詳細な回答をありがとうございます。kexecについて話すことは、おそらく対象読者やこの質問のために不必要に物事を複雑にするだけだと思います。また、ブートローダーのエラーについても重要な点を説明します。

— バリティ14

印刷画面の下に小さなSysRqが書かれていることに気づいたことはありませんでした！これはすごい。カーネルモジュールプログラミングを学んでいたときにこれを知っていたらよかったのに！

— シャーバズ14

再起動する場所を考えることができるのは2回あります。

システムが適切な状態で起動できることを確認する必要がある場合。

私はかつて、実行中にいくつかのデーモンが設定されたシステムで働いていました。数年実行した後、電源障害が原因で再起動しましたが、デーモンは起動プロセスの一部ではなく、数年前にどのように設定されたのか誰にもわかりませんでした。システムの再構成方法を考えている間に、システムは数日間ダウンしていました。

実際に再起動することは、停電後にシステムが適切に再起動することを確認する唯一の方法です。
システムライブラリが更新されたとき。

システム上の多くのアプリ/サーバーと共有されているライブラリで重大なセキュリティ上の欠陥が発見されたとしましょう。再起動せずにライブラリを更新できますが、安全でないライブラリがロードされた状態で実行されているプロセスの数はいくつですか？古いライブラリを使用して何でも苦労して再起動できます（把握できる場合）が、エラーが発生しやすく、再起動するよりも時間がかかる可能性があります。

再起動は、実行中のすべてのプロセスがまだ古いバグのあるライブラリを使用していないことを確認するための最良の方法です。

— ゲーベ
ソース

適切なパッケージマネージャーを使用している場合、特定のライブラリに応じてすべてのバイナリを見つけるより良い方法があります。Gentooからrevdep-rebuiltが思い浮かびます。

— スパイダーマン

@Spidey：これらのバイナリを再構築したら、バグのあるライブラリで実行されている古いプロセスがないことをどのように確認しますか？

— ゲイブ14

どのデーモンに問題のあるライブラリがロードされているかをどのように確認しますか？

— ゲイブ14

@Gabeたとえば、ライブラリlsofをアップグレードする前に、使用しているメモリ空間にライブラリがマップされているプロセスを確認できます。

— トーマスナイマン14

@Gabe確かに、それがリブートする完全に正当な理由であることに同意しますが、OPはリブートがより便利であるケースを明示的に求めませんが、リブートが絶対に必要な場合。

— トーマスナイマン14

ソフトウェア構成の計画的な変更を意味し、完全に機能するハードウェア（まだ見たことがない）とバグのないソフトウェア（ご存知のように...）を想定している場合、カーネルまたはドライバーのバグのみが強制的になりますリブート。:)

それ以外...私はinit、シングルユーザーモードに切り替えて、本質的に再起動とそれほど変わらない魔法を行うことなく交換できるかどうかわかりません。

— ズリン
ソース