ハングしたLinuxサーバーをMagic SysRqキーで安全に再起動する方法・REISUBの手順とsysctl設定

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)Linuxトラブルシューティング > ハングしたLinuxサーバーをMagic SysRqキーで安全に再起動する方法・REISUBの手順とsysctl設定
「サーバーがまったく応答しない。SSHも繋がらない。コンソールに何を打っても反応しない。もう強制電源断しかないのか——」

本番環境のLinuxサーバーがハングアップしたとき、最初に頭をよぎるのが「データが壊れないか」という不安だ。fsyncが完了していない書き込みが残っていれば、電源を引き抜くのは極力避けたい。

この記事では、そういった状況でカーネルが提供する緊急手段——Magic SysRqキーとREISUBシーケンスを解説します。事前のsysctl設定から物理コンソールでの操作手順、/proc/sysrq-triggerを使ったリモート操作、よくある失敗パターンまで体系的にカバーします。動作確認環境はRHEL 9.4 / Rocky Linux 9.4です。

この記事のポイント

・Magic SysRqはカーネルレベルの緊急操作機構で、/proc/sys/kernel/sysrqで有効化する
・REISUBシーケンス(R-E-I-S-U-B)はファイルシステムを守りながら安全に再起動できる
・sysctl -w kernel.sysrq=1 で即座に有効化、/etc/sysctl.d/で永続化する
・SSHが繋がる場合は /proc/sysrq-trigger へのechoコマンドでリモート操作が可能


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P/登録10秒/解除も3秒 / 詳細はこちら

Magic SysRqキーとは何か——カーネルレベルの緊急操作機構

Magic SysRqキーは、Linuxカーネルが提供するデバッグ・緊急操作の機構だ。キーボードドライバとカーネルの間に直接組み込まれており、通常のプロセスがフリーズしていても、カーネル自体が動作している限り操作を受け付ける。

1996年ごろから存在し、当初はカーネルデバッガ用途で実装されたが、現在は運用現場での緊急対応にも広く使われている。x86系アーキテクチャではAlt + SysRq(PrintScreen)キーとの組み合わせで機能を呼び出す。

「カーネル自体が動作している限り」という点が重要だ。カーネルパニックが完全に進行してしまった場合、SysRqは動作しない。SysRqが効くのは、カーネルは生きているが全プロセスがデッドロックしている・リソースを使い果たしている・シェルやXが固まっているといった状況だ。

SysRqで操作できる主な機能は次のとおりだ。

r (Raw):キーボードをXから奪い取りRAWモードに戻す
e (tErminate):init以外の全プロセスにSIGTERMを送信
i (kIll):init以外の全プロセスにSIGKILLを送信
s (Sync):全マウント済みファイルシステムをsync
u (Unmount):全ファイルシステムをread-onlyで再マウント
b (reBoot):即座に再起動(sync処理は省略)
o (Off):電源オフ(APM/ACPI対応環境)
c (Crash):意図的なカーネルクラッシュ(kdump取得用)
t (Tasks):全タスクの状態をカーネルログに出力
m (Memory):メモリ使用状況をカーネルログに出力

REISUBシーケンスとは——各キーの役割と待機時間

REISUBとは、Magic SysRqを使ってファイルシステムへのダメージを最小限に抑えながら安全に再起動するための操作手順の頭文字だ。6つのキーを一定の間隔を置きながら順番に押すことで、単純な電源断より安全な再起動を実現する。

1. R — Raw(キーボードをRAWモードに戻す)

Alt + SysRq + R

キーボードのコントロールをXウィンドウシステムから奪い返し、カーネルに直接入力できるRAWモードにする。サーバー環境ではXが動いていないことが多いが、最初に実行しても害はない。後続のキー入力が確実にカーネルへ届くようにするための準備ステップだ。実行後2秒程度待機する。

2. E — tErminate(全プロセスにSIGTERMを送る)

Alt + SysRq + E

init(PID 1)以外の全プロセスにSIGTERMを送る。プロセスにクリーンアップ処理を行う猶予を与えるステップだ。データベースやWebサーバーがflushを行えるかどうかはここにかかっている。実行後10秒程度待機してプロセスが終了するのを待つ。

3. I — kIll(生き残ったプロセスをSIGKILLで終了)

Alt + SysRq + I

SIGTERMでも終了しなかったプロセスにSIGKILLを送り、強制終了する。これでほぼ全プロセスが停止する。実行後5秒以上待機する。

4. S — Sync(ファイルシステムをディスクに同期)

Alt + SysRq + S

全マウント済みファイルシステムのダーティバッファをディスクに書き出す。このステップがファイルシステム保護の肝だ。実行直後にカーネルメッセージ(コンソールまたはdmesg)にEmergency Syncという文字列が表示されれば成功だ。実行後3秒以上待機する。

5. U — Unmount(全ファイルシステムをread-onlyで再マウント)

Alt + SysRq + U

全ファイルシステムをread-onlyで再マウントする。これによりリブート直前の書き込みが発生しなくなる。カーネルメッセージにEmergency Remount R/Oが表示される。実行後3秒以上待機する。

6. B — reBoot(強制再起動)

Alt + SysRq + B

同期なしで即座に再起動する。SステップとUステップを先に実行しているため、このBは「sync済み・read-only状態での強制再起動」となる。電源断とは異なり、ファイルシステムのデータは保護されている。

Magic SysRqを有効にする方法——sysctl設定

Magic SysRqはデフォルトで無効または部分的にしか有効になっていない。ハングが発生してからでは設定変更が間に合わないため、事前に有効化しておくことが必須だ。

1. 現在の有効化状態を確認する

# /proc/sys/kernel/sysrq の値を確認する cat /proc/sys/kernel/sysrq # sysctl コマンドでも確認できる sysctl kernel.sysrq

検証サーバー(Rocky Linux 9.4)での実行結果:

# cat /proc/sys/kernel/sysrq 16 # sysctl kernel.sysrq kernel.sysrq = 16

16はRHEL 9 / Rocky Linux 9系のデフォルト値だ。/proc/sys/kernel/sysrqの値はビットフラグの組み合わせで意味が決まる。

0:SysRq完全無効
1:全機能有効
16:sync(s)のみ許可(RHEL 9デフォルト)
32:remount(u)のみ許可
64:プロセスシグナル(e, i等)のみ許可
128:再起動(b)のみ許可

デフォルト値16ではsync(S)しか使えない。REISUBの全ステップを実行するには値を1(全機能)に変更する必要がある。

2. 即座に有効化する(再起動すると元に戻る)

# sysctl コマンドで有効化する(推奨) sysctl -w kernel.sysrq=1 # または /proc/sys/kernel/sysrq に直接書き込む echo 1 > /proc/sys/kernel/sysrq

検証サーバーでの実行結果:

# sysctl -w kernel.sysrq=1 kernel.sysrq = 1 # 確認 cat /proc/sys/kernel/sysrq 1

3. 再起動後も有効にする(永続設定)

# /etc/sysctl.d/ に専用ファイルを作成する(推奨) echo "kernel.sysrq = 1" > /etc/sysctl.d/99-sysrq.conf # 設定を即座に反映する sysctl -p /etc/sysctl.d/99-sysrq.conf # または /etc/sysctl.conf に追記する場合 echo "kernel.sysrq = 1" >> /etc/sysctl.conf sysctl -p

/etc/sysctl.d/配下のファイルは数字が大きいものが後から読まれるため、99-sysrq.confという名前にすれば他の設定ファイルに上書きされにくい。

ハング時のREISUB実行フロー——物理コンソールでの操作手順

物理コンソール(直接キーボード接続、またはiDRAC・iLO等のリモートコンソール経由)から操作する前提で説明する。

1. ハング状態の確認

SSHが応答しない、コンソールでキー入力が無視される、サービスが全停止している状態を確認する。まず30秒以上待ってみて、自然回復がないかを見極める。コンソールに何も表示されていなくても、カーネルが生きていれば次のステップに進める。

2. SysRqキーの場所を確認する

多くのキーボードではSysRqはPrintScreen(PrtSc)キーと共用になっている。ラップトップではFn + Alt + PrintScreen + [キー]の組み合わせが必要な場合もある。事前に手元のキーボードで確認しておくとよい。

3. REISUBを実行する

# 以下の操作をコンソールキーボードで順番に実行する # 各ステップの間に必ず待機時間を設ける Step 1: Alt + SysRq + R (RAWモードに切り替え) → 2秒待機 Step 2: Alt + SysRq + E (全プロセスにSIGTERM) → 10秒待機 Step 3: Alt + SysRq + I (全プロセスにSIGKILL) → 5秒待機 Step 4: Alt + SysRq + S (ファイルシステムsync) → 3秒待機 Step 5: Alt + SysRq + U (read-only再マウント) → 3秒待機 Step 6: Alt + SysRq + B (強制再起動)

実行時にコンソールに出力されるカーネルメッセージの例:

# SysRq + E 実行後 SysRq : Terminate All Tasks # SysRq + S 実行後 SysRq : Emergency Sync Emergency Sync complete # SysRq + U 実行後 SysRq : Emergency Remount R/O

Emergency Sync completeEmergency Remount R/Oが表示されたことを確認してからBを押すと、より安全だ。

Linuxカーネルのトラブルシューティングを体系的に学び、障害発生時に自信を持って対処できるスキルを身につけたい方には、Linuxマスター上級コースで実務ベースの緊急対応手順を学ぶ機会もある。SysRqのような緊急対応を「知っている」から「確実に使える」レベルに引き上げるための実践的な内容だ。

/proc/sysrq-triggerによるリモート実行

物理コンソールが使えなくても、SSHが繋がる状態であれば/proc/sysrq-triggerにechoコマンドを書き込むことでSysRqを操作できる。

1. リモートからのREISUB手順

# root権限が必要(sudo も使用可) # Step 1: RAWモード(リモートでは通常スキップ可) echo r > /proc/sysrq-trigger # Step 2: 全プロセスにSIGTERM(実行後10秒待機) echo e > /proc/sysrq-trigger sleep 10 # Step 3: 全プロセスにSIGKILL(実行後5秒待機) echo i > /proc/sysrq-trigger sleep 5 # Step 4: ファイルシステムsync(実行後3秒待機) echo s > /proc/sysrq-trigger sleep 3 # Step 5: read-only再マウント(実行後3秒待機) echo u > /proc/sysrq-trigger sleep 3 # Step 6: 強制再起動 echo b > /proc/sysrq-trigger

注意:リモートで実行する場合、echo e(SIGTERM)を実行するとSSHセッション自体が切断される可能性がある。セッションが切断されても残りのコマンドが実行されるよう、シェルスクリプトとして一括投入するか、screenやtmuxのセッション内で実行することを推奨する。

2. nohupで一括実行する(SSH切断対策)

#!/bin/bash # /usr/local/sbin/emergency-reisub.sh # ハング時の緊急再起動スクリプト(root必須) SYSRQ=/proc/sysrq-trigger logger -t REISUB "=== REISUB 緊急再起動シーケンス開始 ===" echo r > $SYSRQ ; sleep 2 logger -t REISUB "E: Sending SIGTERM to all processes" echo e > $SYSRQ ; sleep 10 logger -t REISUB "I: Sending SIGKILL to all processes" echo i > $SYSRQ ; sleep 5 logger -t REISUB "S: Syncing filesystems" echo s > $SYSRQ ; sleep 3 logger -t REISUB "U: Remounting read-only" echo u > $SYSRQ ; sleep 3 logger -t REISUB "B: Rebooting now" echo b > $SYSRQ

このスクリプトをnohupで実行すれば、SSH切断後も継続して動作する。

# nohup で実行(SSH切断後も動作) nohup bash /usr/local/sbin/emergency-reisub.sh > /tmp/reisub.log 2>&1 &

よくあるトラブルパターンと注意点

【失敗1】Alt+SysRq+キーを押しても何も起きない

最も多いケースだ。原因の大半は事前設定の不備だ。

SysRqが無効になっている:cat /proc/sys/kernel/sysrqが0または目的の機能に対応するビットが立っていない。ハング前にsysctl -w kernel.sysrq=1で有効化しておく必要がある
USB接続キーボードの問題:USBドライバ自体がフリーズしているとSysRqも動作しない。PS/2接続キーボードのほうが信頼性が高い
SELinuxがブロックしている:enforcing環境では/proc/sysrq-triggerへの書き込みがブロックされることがある。/var/log/audit/audit.logでDENIEDメッセージを確認する

【失敗2】Sステップ(sync)でコンソールが固まる

I/Oが詰まっている状態でsyncを実行すると、I/Oの完了を待って数十秒固まることがある。この場合は根気よく待つ。1分以上経過しても反応がなければ、Uをスキップして直接Bに進む(fsckが起動することになるが、強制電源断よりはましだ)。

【失敗3】仮想環境やリモートコンソールでキーが届かない

VMwareやKVMのVNCコンソール、WebベースのリモートコンソールではAlt+SysRqのキーコンビネーションがホスト側にインターセプトされることがある。

KVM/QEMU:virt-managerの「Send Key」メニューからSysRqシーケンスを送れる
クラウドVM(AWS EC2等):EC2 Serial Consoleが有効になっていればSysRqが使える。有効でなければ/proc/sysrq-triggerへのechoコマンドで代替する

【失敗4】BとOを押し間違える

「B(reBoot)」の代わりに「O(Off)」を押すと電源オフになる。再起動のつもりが電源断になってしまうミスだ。特にKVM仮想マシンでは電源OFFから手動で再起動が必要になる。再起動したい場合は必ずBを使う。

【重要】REISUBはあくまで緊急手段

REISUB経由の再起動でも、Eステップで正常終了しなかったプロセスのアプリケーションデータは完全にクリーンアップされない可能性がある。データベース(MySQL/PostgreSQL等)やトランザクションキャッシュのあるアプリケーションは、再起動後に整合性チェック(fsck、DB内蔵のリカバリ機能)を必ず実行すること。

まとめ

Magic SysRqとREISUBシーケンスは、ハングしたLinuxサーバーを「強制電源断」よりも安全に再起動するための標準的な緊急手順だ。事前のsysctl設定なくしては使えないため、サーバーセットアップ時に有効化を済ませ、永続設定まで入れておくことを強く推奨する。
やりたいこと コマンド / 操作
SysRqの現在値を確認 cat /proc/sys/kernel/sysrq
SysRq全機能を即座に有効化 sysctl -w kernel.sysrq=1
SysRqを永続的に有効化 echo "kernel.sysrq = 1" > /etc/sysctl.d/99-sysrq.conf
全プロセスにSIGTERM(リモート) echo e > /proc/sysrq-trigger
全プロセスにSIGKILL(リモート) echo i > /proc/sysrq-trigger
ファイルシステムsync(リモート) echo s > /proc/sysrq-trigger
全FSをread-only再マウント(リモート) echo u > /proc/sysrq-trigger
強制再起動(リモート) echo b > /proc/sysrq-trigger
再起動後はsystemd-analyze で起動時間計測でブート時間の異常がないかを確認し、Linux ポート確認の全コマンドでサービスが正常にリッスンしているかをチェックするとよい。

ハング対応を乗り越えたら、次はLinuxサーバー運用の「型」を体系的に固めませんか?

REISUBで今回は乗り越えられても、ハングの根本原因(OOM・I/O枯渇・カーネルバグ)を特定して次を防ぐには体系的な知識が必要です。カーネルパラメータ・ログ監視・リソース設計をまとめて身につけることで、緊急対応に頼らない安定稼働が実現できます。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。

「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒/合わなければ解除3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。