サーバーを再起動する方法は？ -これは通常、halt、shutdown -r、reboot、init 6などの間で混乱する初心者ユーザーに尋ねられる質問です。
経験豊富な管理者が「サーバーの何が問題なのか」という質問を明確にします。さまざまな種類のサーバーの障害にはさまざまな種類の再起動が必要です。最も簡単です。 私の個人的な練習で最も難しいことは、エニケイスキクが近隣の都市に旅行したことです。 孤独なサーバーで「再起動をクリック」するため。
この記事の内容：サーバーの再起動を妨げるものとその解決方法。
リブート理論から始めましょう。
サーバーがシャットダウンまたは再起動すると、初期化マネージャー（ほとんどの最新のディストリビューション-systemd、これまでの異常なUbuntu 14.04のアップスタート、古風なジャンク-sysv-init）は、特定の順序ですべてのデーモンにシャットダウンするコマンドを送信します。 また、ほとんどのデーモン（mysqlなどのDBMSなど）は、正しくシャットダウンする方法を知っています。 たとえば、すべてのトランザクションを終了する、保存されていないデータをすべてディスクに保存するなど。 redisのようなインメモリDBMSの場合、これは非常に重要です。保存されていない-失われています。
古い初期化システムは、各スクリプトを無期限に待機していました。 たとえば、「いたずら」が「スリープ」に「sleep 3600」ブランチを追加した場合、サーバーは1時間テールで再起動します。 そして、より大きな数、または終了したくないプログラムだけがある場合、再起動は終了しません。
新しい初期化システム（実際、恥ずかしがり屋ではありません-systemdのみが残っています）は、データを保存するために一定のタイムアウト（通常120または180秒）を与え、その後強制的にプロセスを完了します。 デーモンの停止に加えて、ファイルシステムはマウント解除されます（つまり、すべてのブロックキャッシュが削除されます）、iscsiターゲットは停止します（キャッシュのフラッシュも行います）。 など シャットダウン時間が無期限に長いという事実にもかかわらず、もちろんすべて同じです。 さらに、すべてのデーモンが正しく完了し、ファイルキャッシュが削除されるなど、少なくともある程度の希望があります。
したがって、正常なシステムでは、「再起動方法」という質問に対する正しい答えは、再起動コマンドを実行することです。 場合によっては、それだけで正しいこともあります（修正：グラフィカルインターフェイスで「再起動」すると、デスクトップ環境はこれが再起動であると判断します。グラフィカルインターフェイスから再起動するには、DEインターフェイスで「再起動」を使用する必要があります）。
「通常の再起動」で何が問題になる可能性がありますか？ まあ、まず第一に、デーモンプロセスのいくつかは「愚か」になり始めるかもしれません-上記を参照してください。
第二に、ファイルシステムのマウント解除に問題がある可能性があります。 すべてのプロセスを「強制終了」するだけで十分であると考えられており、ディスクを簡単にアンマウントできます。誰も使用しません。 しかし、控えめに言っても、これはそうではありません。 「アンマウントされないように爪を爪で釘付けする潜在的な方法は次のとおりです。
- fallocate / fs / swap -l 1G; mkswap / fs / swap; swapon / fs /スワップ
- dd if = / dev / sda of = / fs / image; kpartx / fs /イメージ
- losetup --find --show / fs / image
など 要するに、ファイルはファイルシステムだけでなく、カーネルによっても占有される可能性があります。 そして、カーネル内のモジュールは、人生の意味に対する答えを探すのに忙しく、リソースを解放する意図がないかもしれません。
これは何でいっぱいですか？ マウントされていないファイルシステム。 この状況でSystemdは、試行、試行、およびスロー（マウント解除されたファイルシステム）します。 つまり、この状況での再起動は非常に長くなりますが、それでもパスします。 しかし、それはumountがエラーを返す場合です。
そして、何かが利用できないために、umountが操作を完了できないことがあります。 たとえば、nfsサーバー上のファイル。 プロセスがそのようなファイルにアクセスする場合、（kill -9を使用しても）終了できません。 そして、この状況では、「リブート」はサーバーをハングさせるだけです。 繰り返しますが、systemdの最も一般的な場所は「カバー」されていますが、TASK_UNINTERRUPTIBLE（ps auxの「D」）につまずく可能性はまだあります。
どうする ファイルシステムを同期せずに再起動できます。再起動-fを完了します。 しかし、彼はまたハングすることができます。 以下の理由についてですが、今のところは結果についてです。すべてのプロセスが停止してすぐに死ぬわけではなく、tcpセッションは閉じられず、ディスクキャッシュはフラッシュされません。 ただし、カーネルは再起動領域で何らかの移動を実行します（場合によっては、一部のキャッシュが削除されます）。 主なことは、ほとんどのカーネルが再起動プロセスに関与することです。 これは、カーネルが病気の場合、戻ってこない可能性があることを意味します。
2番目の、非常に不快な状況：/（ルート内の）上のファイルシステムの問題。 ls、grep、さらには「reboot」を実行しようとすると、コンソールがハングするかエラーが発生します。 libcの問題（削除を含む）は、「リブート」してリンクの問題について話し、何かを拒否しようとすると同じカテゴリに分類されます。 または、pidの数の制限に達したため、それらはすべて「D」状態にあります。 または同じ口径の他のマック、「不良サーバー」カテゴリに移動します。
そのため、サーバー上で開いているコンソールは1つだけです（2つ目のコンソールはもう開きません）。 なんで？ 誰かがディスクドライバーで何かをしたからです。 または襲撃コントローラー。 または、ディスクキャッシュ内のメモリのみが「/」から残ります。 つまり、新しいプロセスを開始せずに実行するbashコマンド（ビルトイン）しかありません。
実行可能ファイルの実行を必要としない再起動方法があります（つまり、見つからないドライブからの読み取り）。 これ（ルートから）：
echo b >/proc/sysrq-trigger
。 sysrq-triggerファイルを使用すると、SysRqの組み合わせの任意のボタン（カーネル緊急ボタン）を「押す」ことができます。 SysRq-bを含む、つまり緊急の「再起動」。 Enterキーを押した後、ラインフィードに表示する時間さえないことがよくあります。syscallが戻る前に、サーバーはすでに再起動中です。 これは、再起動用のソフトウェアの中で最も強力です。
注：この状況では正しいと思われる「同期、再起動」、つまり SysRq-s、SysRq-Bはエラーです。 SysRq-Sの後、カーネルは空のアレイとの通信を開始しようとし、パニックを起こしたり、最後に使用可能なコンソールを切断したりする可能性があります。 緊急リブートが行われた場合-緊急でなければなりません
ipt_sysrq
サーバーにコンソールがある場合、これはすべて機能します。 そして、ログインがハングし、開いているコンソールがない場合はどうなりますか？ 特定のネットワークパケットを受信するsysrq要求を実行できるipt_SYSRQモジュールがあります（より正確には、iptablesルールに従って）。 それは完全にカーネルで動作します、すなわち FSに依存しません。 send_sysrqコマンドが添付されています。
番人のための番人
これは「すべて」であると考えられますが、さらに不快なフリーズがあります。 たとえば、ネットワークカードがハングします。 そして、通常の再起動（sysrq経由を含む）は役に立ちません。 このような悪い状況の2番目の例は、エンクロージャーの凍結です。これは、不良ディスクにスタックし、すべてのバスリセットを無視します。 再起動するとすべてがリセットされるようですが、ディスクにアクセスできません。
この場合、電源の再投入（有効化/無効化）が必要です。 サーバーへの物理的な実行はおもしろくないので、最新のサーバーの機能であるIPMIを見ることができます。 これは、組み込みのマイクロコンピューターで、「大型」コンピューターを制御できます。 通常、IPMI、DRAC、iLOなどと呼ばれます。
興味のあるチーム：ipmitool chassis power cycle システムの健全性がより要求されます（カーネルモジュールをロードする必要がある、ipmitool自体が正常に起動する必要がある、ipmiが動作している必要があるなど）。 しかし、それはすべての栄養をゆがめることができます。 より正確には、ほとんどすべて-サーバーにjbodsがある場合、このコマンドはjbodsに到達しません。 しかし、それでも、これは非常に安定した優れた再起動です。
カーネルが完全にスタックしている場合、コマンドをリモートで実行できます（ipmitool -H ipmi.server.local chassis power cycle）
別の困難な状況は、ipmiがハングするときです。 システムが多かれ少なかれ稼働している場合、「ipmiを再起動」できます：
ipmitool mc reboot hard
。 その後、シャーシの電源を入れ直すことができます。 奇妙に聞こえますが、私の人生で数回、そのようなシーケンスで通常のリブートにサーバーを「引き出し」ました。 （ mcをハードリブートした後、BMCをダウンロードするのに数分かかります ）。
「痛み」の次のポイントは、電源の凍結です。 はい、それは起こります。 電源のファームウェアのバグは修正されており、 フラッシュする必要があります。 もちろん、この状況ではソフトリブート（ipmi電源サイクルなど）は機能しません。 ケーブルを物理的に突くか、電源をリモートで歪ませる必要があります。 この状況では、IPコンセントが役立ちます。
次のようになります（servers.com/servers.ruのコントロールパネルの断片）：
明らかに、これらの条件下では、再起動は非常に厳しいシナリオを通過しますが、間違いなくパスします。
おわりに
簡単なスクイーズ
| 通常の仕事 | 再起動 |
| ソフトウェアの問題 | リブート-f |
| カーネル/マウント/ libcの問題 | エコーb> / proc / sysrq-trigger |
| カーネル/マウント/ libcに問題があり、コンソールが開いていない | ipt_SYSRQ（事前に準備する必要があります） |
| コア/ハードウェアの問題 | ipmitool chassis power cycle |
| オープンコンソールなしのカーネル/ハードウェアの問題 | ipmitool -H ipmi.server.local chassis power cycle |
| 自律型周辺機器の問題/ BP / ipmi | IPコンセントから再起動する |