文章源自：http://www.ibm.com/developerworks/cn/linux/l-cn-sysrq/

SysRq 是什么

你是否遇到服務器不能通過 SSH 登錄，也不能通過本地終端登錄，但是卻能 ping 通，數字鍵盤鎖還可以響應擊鍵操作的情況？在這種情況下，你除了按下電源或復位鍵之外，還做過什么嗎？你是否想過這種情況是可能恢復的呢？你是否想過收集更多的信息來定位這次系統掛起的原因呢？上述情況，可稱之為“可中斷的系統掛起”。換句話來講，系統因為某種原因已經停止對大部分正常服務的響應，但是系統仍然可以響應鍵盤的按鍵中斷請求。在這種情況下，一組稱為 SysRq 的按鍵組合將發揮它的神奇作用。

SysRq 經常被稱為 Magic System Request，它被定義為一系列按鍵組合。之所以說它神奇，是因為它在系統掛起，大多數服務已無法響應的情況下，還能通過按鍵組合來完成一系列預先定義的系統操作。通過它，不但可以在保證磁盤數據安全的情況下重啟一臺掛起的服務器，避免數據丟失和重啟后長時間的文件系統檢查，還可以收集包括系統內存使用，CPU 任務處理，進程運行狀態等系統運行信息，甚至還可能在無需重啟的情況下挽回一臺已經停止響應的服務器。

啟用 SysRq

內核的支持

要啟用 SysRq 功能，首先必須確保內核已經加入 CONFIG_MAGIC_SYSRQ 支持。在現今 Linux 發行版中，無一例外的均已加入該功能的支持，驗證如下：

# grep “ CONFIG_MAGIC_SYSRQ ” /boot/config-`uname – r`

CONFIG_MAGIC_SYSRQ=y

通過 sysctl 啟用

SysRq 功能默認在 RHEL5u2 上是禁用的。可以通過 proc 文件系統來啟用它。使用 sysctl 命令啟用它，并通過 /proc 來檢查其可用性。

# sysctl -w kernel.sysrq=1

kernel.sysrq = 1

# cat /proc/sys/kernel/sysrq

1

kernel.sysrq 還可接受除 0 和 1 以外的啟用參數，詳情請參考 sysrq 內核文檔。

保持重啟后生效

通過把” kernel.sysrq = 1 ”設置到 /etc/sysctl.conf 中，可以使 SysRq 在下次系統重啟后仍然生效。請注意，在非 RHEL 系統中，也許需要通過其它的配置文件來使之重啟后生效。

使用 SysRq

網上有道題，問在 shell，init、halt、shutdown 等命令都不工作的情況下如何重啟系統。答案就是 SysRq，通過 SysRq – B 來完成系統的重啟。

早期的 SysRq 只支持鍵盤操作。要使用 SysRq，必須直接對主機進行鍵盤操作。要想執行 SysRq-B 來重啟系統，只能通過直接鍵盤操作 Alt – SysRq – B 來完成(這里的 B 僅指 B 按鍵，不區分大小寫)。 kernel 2.5.64 上的一個 patch 增加了 /proc/sysrq-trigger 接口，使得用戶可能通過 /proc 接口來進行 SysRq 操作，換而言之，在現今大部分構建在 2.6 內核上的發行版，對主機鍵盤的物理接觸已經不再是 SysRq 的必要條件。用戶只需要登錄到系統上，就可以直接使用echo “ b ” > /proc/sysrq-trigger 來重啟系統。在下文中，為描述的簡潔，SysRq-> 均代表 Alt-SysRq-> 或者 echo “ ? ” > /proc/sysrq-trigger 。

眾所周知，系統掛起的很多時候 ssh 登錄也未必響應，在缺乏對主機物理操作條件下，/proc/sysrq-trigger 也因為無法獲取登錄 shell 而無法操作。于是出現了一個名為 sysrqd 的開源項目，它允許通過網絡來直接來觸發 SysRq 。該程序只有 300 行左右代碼，監聽 TCP 端口 4094，通過自定義密碼驗證過后，即可對 /proc/sysrq-trigger 進行操作。但是由于此程序在用戶空間實現，在系統掛起時該程序的可用性，以及其安全性均受到廣泛質疑。其實如果這個服務做到內核空間，以類似響應 ARP 形式進行處理，再加上合理的認證方式，或許在大多數系統掛起的時候可以起到更加實際的作用。當然，在現代服務器的遠程管理模塊日趨先進的前提下，是否能通過網絡來觸發 SysRq 好像并不是那么重要。

查看 SysRq 輸出

SysRq 并不只能重啟服務器，如果只是這樣，那我們也不需要查看它的輸出了。很多時候，我們使用 SysRq 是為了查看服務器的 CPU，內存或進程信息。 SysRq 默認會輸出到本地控制臺終端，并寫入 syslog，但這并不是個好主意。因為對于大多數系統掛起的情況，我們已經無法再訪問這兩個信息源，在無法判定系統故障的情況下，只好無奈的使用后面即將介紹的 R-E-I-S-U-B 序列來重啟服務器。接下來將介紹 SysRq 輸出的幾種方法。只有最大程度的獲取到 SysRq 輸出，才能更好的利用 SysRq 提供的其它功能。

輸出到本地終端

SysRq 默認會根據 console_loglevel 輸出到本地終端。只要 console_loglevel 大于 default_message_loglevel，SysRq 信息就會輸出到本地控制臺終端。它在測試的時候都好用，但一到關鍵時刻，系統掛起無法切換，大量輸出造成滾屏，以及信息無法記錄等問題隨之而來。

輸出到 syslog

根據 syslog 的默認配置，SysRq 默認會記錄到 /var/log/messages，并且這里記錄的信息與 console_loglevel 無關，基本是完整的。但是由于負責記錄日志的 syslogd 本身也是一個用戶進程，在執行后面即將介紹的 SysRq-E, SysRq-I 時也會被終結，這就意味著 syslog 記錄的信息在一定情況下將不再完整。同時由于系統掛起時查看 syslog 日志本身就是一件難上加難的事，這里記錄的信息往往只能用在系統恢復過后的故障分析，對故障發生時的實時診斷并沒有太大的幫助。

通過 netconsole 輸出

利用 netconsole 功能，可以獲得一個通過遠程 syslog 服務器輸出的顯示終端，服務器的 SysRq 輸出將被遠程的 syslog 服務器捕獲。在服務器掛起，無法查看 syslog 日志，同時也無法切換到本地控制臺終端的時候，這種形式的輸出就顯得舉足輕重。與本地終端類似，只要 console_loglevel 大于 default_message_loglevel，SysRq 信息就會通過 netconsole 輸出到遠程。它在大多數情況都生效，哪怕是內核網絡部分出現問題。因為 netconsole 的網絡發送部分是獨立存在的，并不依賴于網卡驅動程序。

輸出到串口終端

要想通過串口獲取 SysRq 輸出，首先需要在 grub 的 kernel 行添加類似 ” console=ttyS0,115200 ” 的串口輸出配置，重啟服務器以啟用內核串口輸出。然后從另一臺主機上用串口線連接服務器，并用 minicom 等程序捕獲其輸出。這是一種通常的使用方式。然而利用 Serial over IP 產品，管理員無需現身嘈雜的機房就能通過網絡獲得服務器的串口輸出，查看并截取字符形式的輸出。這是相對現代的使用方式。通過這兩種方式，我們都可以方便的獲取到 SysRq 在串口上輸出。

SysRq 功能鍵組合

安全重啟系統

到目前為止，我們可見到的大多數 SysRq 推薦用法都是系統掛起后的安全重啟，用此方法來避免數據丟失。這個 SysRq 序列是 R-E-I-S-U-B 。要知道，該序列早在 SysRq 首次于 Linux 實現的 2.1.43 內核中就存在了。它基本等價于 reboot 命令，會依次停止系統上運行的進程，回寫磁盤緩沖區，再安全的重啟系統。需要注意的是，E 會向除 init 以外所有進程發送可捕獲的 SIGTERM 信號，這就意味著程序可能需要一定時間來進行結束進程前的善后處理，視系統負載和任務數量，這個時間可能會達到幾十秒。 I 發送的是不可捕獲的 SIGKILL 信號，相對而言沒有更多的延遲。同時，S 和 U 這兩個動作均與磁盤相關。當系統具有一定負載時，這兩個動作均不會立即完成，而是需要一定的時間，通常為幾秒鐘。所以，R-E-I-S-U-B 這個序列的推薦使用方式是：R – 1 秒 – E – 30 秒 – I – 10 秒 – S – 5 秒 – U – 5 秒 – B，而不是一氣呵成地按下這六個鍵，試想一次正常的 reboot 命令也不是在一瞬間完成的吧。

下面列出各個序列的示例輸出及簡單說明：

R - 把鍵盤設置為 ASCII 模式

SysRq: Keyboard mode set to XLATE

有關鍵盤工作模式，請參考資料中的??手冊。

E - 向除 init 以外所有進程發送 SIGTERM 信號

SysRq: Terminate All Tasks

因為 syslogd 本身也被結束，所以 SysRq 也許不會被記錄下來。但是查看 /var/log/messages 會看到類似下面的消息：

exiting on signal 15(SIGTERM)

I - 向除 init 以外所有進程發送 SIGKILL 信號

SysRq: Kill All Tasks

與 E 類似，因為 syslogd 本身也被結束，除非 netconsole 或串口記錄已打開，否則連上面的信息都無法捕捉。同時，因為 SIGKILL 是不可捕獲的信號，/var/log/messages 里面也不會留下任何線索。

S - 磁盤緩沖區同步

SysRq : Emergency Sync

Emergency Sync complete

該操作會把磁盤緩沖區的數據回寫，以防止數據丟失，通常會有一定延時。在能看到輸出的情況下，請等到 ” Emergency Sync complete ” 過后再繼續后續操作。否則，等十秒鐘左右，再進行后續 SysRq 操作。

U - 重新掛載為只讀模式

SysRq : Emergency Remount R/O

Emergency Remount complete

該操作會把磁盤重掛載為只讀模式，以防止數據的損壞。與 S 類似，該操作通常也有一定延時。請等到 ” Emergency Remount complete ” 出現過后再進行后續操作，或者等候十秒鐘再進行后續 SysRq 操作。

B - 立即重啟系統

SysRq: Resetting

該操作會立即重啟系統，比想象中要快。

恢復系統掛起

僅從系統掛起后安全重啟來看，R-E-I-S-U-B 序列似乎已經令人滿意了。但對于一些掛起，只是因為一部分進程消耗過多 CPU，內存等系統資源引起的。對于這樣的情形，可以通過結束“兇手”進程來恢復已經掛起的系統。

筆者曾親歷 Acrobat Reader 在 Firefox 中內存泄露引起的系統掛起。每在 Firefox 中瀏覽完成一個 PDF 后，acroread 進程不會退出，相反其內存使用量逐步攀升，在一段時間內消耗完系統的內存和 swap，系統持續 swapping，使系統進入掛起狀態，不響應桌面，鼠標，以及所有的應用程序。

筆者還經歷一例屏保程序引起的系統掛起。鎖定一段時間后，鍵盤鼠標停止響應，無法切換到本地控制臺，遠程登錄正常，查看內存使用正常，CPU 被屏保程序吃盡。

SysRq 定義了一組與結束進程相關的序列：E-I-K-F，我們可以用它們來恢復系統掛起。

E 和 I 已經介紹過，他們都會結束除 init 以外的所有進程，理所當然都可以恢復類似的系統掛起。筆者在早期也是這樣做的。但是這種方法似乎過于暴力，恢復過后的系統基本上除了 uptime 是連續的，數據未損壞以外，余下的狀態并不比重啟一次系統好。因為所有的服務都已中止，還需手工干預才能恢復正常。筆者的經驗，經過 E-I 恢復的系統，如不是時間緊迫，即使系統已經恢復響應，最好繼續完成 S-U-B 操作。因為對于一些復雜業務系統，難免因為人為因素造成某些服務忘記啟動而埋下日后的定時炸彈。

K 和 F 正是它們的補充。它們僅結束符合特定條件的進程。 K 只結束與當前控制臺相關的進程組。 K 代表 saK，saK 的全稱為 Secure Access Key 。從字面意思看似乎有些深奧，它的本意是出于安全考慮，為了殺掉類似木馬一類套取密碼的偽登錄程序，讓 init 重新啟動正在的 getty 登錄界面。但在實際應用過程中，特別在 X 窗口下某些程序內存泄露或其它異常行為引起系統掛起時，就像上面兩個例子，可以相當準確而快捷的使系統恢復正常。在理解 SysRq-K 之前，筆者曾一度使用 SysRq-E 來解決問題，但隨之而來的系統服務恢復則成了一大難題。 F 則利用 OOM-Killer 選取一個進程然后結束之。這對于內存問題引起的掛起可以起到比 SysRq-K 更加準確的作用。但是有些時候 OOMKiller 也會誤判而殺掉一些長時間運行的后臺服務，引起一些不必要的麻煩。

下面列出各個序列的示例輸出及簡單說明：

E - 向所有進程發送 SIGTERM 信號

SysRq: Terminate All Tasks

I - 向所有進程發送 SIGKILL 信號

SysRq: Kill All Tasks

K - 結束與當前控制臺相關的全部進程

SysRq : SAK

SAK: killed process 7254 (top): p->signal->session==tty->session

SAK: killed process 7223 (bash): p->signal->session==tty->session

該操作結束了文本控制臺下正在運行的 top 程序，以及登錄的 shell 。

F - 人為觸發 OOM Killer

SysRq : Manual OOM execution

events/0 invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0

[] out_of_memory+0x72/0x1a5

[] moom_callback+0x13/0x15

[] run_workqueue+0x78/0xb5

[] moom_callback+0x0/0x15

[] worker_thread+0xd9/0x10b

[] default_wake_function+0x0/0xc

[] worker_thread+0x0/0x10b

[] kthread+0xc0/0xeb

[] kthread+0x0/0xeb

[] kernel_thread_helper+0x7/0x10

=======================

Mem-info:

…… (snip) ……

Out of memory: Killed process 4860 (xfs).

該操作人為觸發 OOM Killer，OOM Killer 將根據各進程的內存處理情況選取最合適的“兇手”進程，并向其發送 SIGKILL 信號，中止其運行。 SysRq 輸出包括運行棧，內存使用信息，和“兇手”進程的標識信息。在此例中 PID 為 4860 的 xfs 進程被中止。在實際情況中，除非可以確認是內存使用問題，盡量避免使用這個組合鍵。因為 OOM-Killer 自動挑選的進程不一定是真正的“兇手”。相比之下，SysRq-K 結束的進程更有針對性，特別是對 X 桌面下程序引起的系統掛起。由于桌面下啟動的程序多數為非關鍵應用，結束并重啟它們在大多數情況下并不會對系統造成太多影響。

考慮篇幅關系，省略了內存情況的輸出，因為這部分與 SysRq-M 輸出一致。

獲取系統信息

SysRq 提供了 M-P-T-W 序列，在恢復系統掛起之前，這是一個推薦執行的序列。它會記錄下當前系統的內存使用情況，當前 CPU 寄存器的狀態，進程運行狀態，以及所有 CPU 及寄存器的狀態。通過這些信息，可以對掛起的原因做粗略的分析，然后結合之前介紹的 E-I-K-F 序列對癥下藥進行恢復性操作，或許還可以即時恢復一部分已經掛起的系統，而不是每遇到系統掛起就盲目的按電源，或機械地操作 R-E-I-S-U-B 序列。就算不能找到原因并成功恢復，也將會為以后的故障分析留下寶貴的證據。要知道，能通過 syslog 找出原因的系統掛起少之又少。

下面列出各個序列的示例輸出及簡單說明：

M - 打印內存使用信息

SysRq : Show Memory

Mem-info:

DMA per-cpu:

cpu 0 hot: high 0, batch 1 used:0

cpu 0 cold: high 0, batch 1 used:0

DMA32 per-cpu: empty

Normal per-cpu:

cpu 0 hot: high 186, batch 31 used:12

cpu 0 cold: high 62, batch 15 used:13

HighMem per-cpu: empty

Free pages: 94460kB (0kB HighMem)

Active:34941 inactive:64962 dirty:1 writeback: 0 unstable:0 free:23615 slab:3755

mapped-file:2075 mapped-anon:7412 pagetables:3 26

DMA free:12016kB min:88kB low:108kB high:132kB active:16kB inactive:0kB

present:16384kB pages_scanned:0 all_unreclaimable? no

lowmem_reserve[]: 0 0 496 496

DMA32 free:0kB min:0kB low:0kB high:0kB active :0kB inactive:0kB

present:0kB pages_scanned:0 all_unreclaimable? no

lowmem_reserve[]: 0 0 496 496

Normal free:82444kB min:2804kB low:3504kB high :4204kB active:139748kB

inactive:259848kB present:507904kB pages_scanned:0 all_u nreclaimable? no

lowmem_reserve[]: 0 0 0 0

HighMem free:0kB min:128kB low:128kB high:128k B active:0kB inactive:0kB

present:0kB pages_scanned:0 all_unreclaimable? no

lowmem_reserve[]: 0 0 0 0

DMA: 38*4kB 37*8kB 33*16kB 29*32kB 24*64kB 17* 128kB 9*256kB

4*512kB 0*1024kB 1*2048kB 0*4096kB = 12016kB

DMA32: empty

Normal: 1*4kB 1*8kB 124*16kB 110*32kB 54*64kB 52*128kB 103*256kB

31*512kB 20*1024kB 2*2048kB 0*4096kB = 82444kB

HighMem: empty

92491 pagecache pages

Swap cache: add 0, delete 0, find 0/0, race 0+ 0

Free swap = 1048568kB

Total swap = 1048568kB

Free swap: 1048568kB

131072 pages of RAM

0 pages of HIGHMEM

2263 reserved pages

26019 pages shared

0 pages swap cached

1 pages dirty

0 pages writeback

2075 pages mapped

3755 pages slab

326 pages pagetables

該操作顯示了 cpu 相關分區信息，全局頁使用情況，分區頁使用情況，分區 slab 使用情況，頁緩存使用情況，swap 使用情況等等。

P - 打印當前 CPU 寄存器信息

SysRq : Show Regs

Pid: 0, comm: swapper

EIP: 0060:[] CPU: 0

EIP is at __do_softirq+0x51/0xbb

EFLAGS: 00000286 Not tainted (2.6.18-92.el5 #1)

EAX: c0722380 EBX: 00000002 ECX: c072b000 EDX: 00ce1e00

ESI: c06ddb00 EDI: 0000000a EBP: 00000000 DS: 007b ES: 007b

CR0: 8005003b CR2: b7f85000 CR3: 14d6f000 CR4: 000006d0

[] do_softirq+0x52/0x9d

[] apic_timer_interrupt+0x1f/0x24

[] default_idle+0x0/0x59

[] default_idle+0x31/0x59

[] cpu_idle+0x9f/0xb9

[] start_kernel+0x379/0x380

=======================

該操作顯示了正在執行的進程名，運行函數，寄存器上下文，以及程序的調用棧回溯等信息。這對于分析死鎖引起的系統掛起有著非常重要的作用。一般來說我們會多采幾次重復樣本，以便更加準確的做出系統運行狀態的判斷。

T - 打印進程列表

SysRq : Show State

sibling

task PC pid father child younger older

…… (snip) ……

syslogd S 00003280 2104 4313 1 4316 4279 (NOTLB)

dfc1cb68 00000082 b9d5334a 00003280 dd931a70 dd931a70 e08e9376 00000007

dfc1eaa0 c06713c0 b9d85c35 00003280 000328eb 00000000 dfc1ebac c1404fe0

00000010 df4f79c0 df4bd53c c0457dc0 df6438f4 ffffffff 00000000 00000000

Call Trace:

[] ext3_mark_iloc_dirty+0x2d8/0x333 [ext3]

[] mempool_alloc+0x28/0xc9

[] schedule_timeout+0x13/0x8c

[] datagram_poll+0x15/0xb8

[] do_select+0x371/0x3cb

[] __pollwait+0x0/0xb2

…… (snip) ……

[] do_setitimer+0x4a6/0x4b0

[] sys_select+0xcf/0x180

[] syscall_call+0x7/0xb

=======================

klogd R running 2664 4316 1 4369 4313 (NOTLB)

該操作顯示了進程列表，包含各進程的名稱，進程 PID，父 PID 及兄弟 PID 等相關信息，以及進程的運行狀態。對于正在運行中的進程(R)，沒有太多的信息。對于處于睡眠狀態的進程，列出其調用棧回溯信息，以便進行調試跟蹤。由于篇幅關系，去掉了大部分冗余的信息。

W - 打印 CPU 信息

SysRq : Show CPUs

CPU0:

c074be84 00000000 00000000 c053a1fa d23c0000 c0406531 c062ccf1 c0650e94

00000000 00000000 c053a221 c0641b83 00000000 c042a111 00000000 c068c630

00000001 00000077 c053a0cd 00000000 c053a14d c0640322 c0641d0f c06e7fa4

Call Trace:

[] showacpu+0x0/0x32

[] show_stack+0x20/0x25

[] showacpu+0x27/0x32

[] on_each_cpu+0x17/0x1f

[] sysrq_handle_showcpus+0x10/0x12

[] __handle_sysrq+0x7e/0xf6

[] handle_sysrq+0x10/0x12

[] kbd_event+0x2e0/0x507

[] input_event+0x3e6/0x407

[] atkbd_interrupt+0x3f5/0x4da

[] serio_interrupt+0x33/0x6a

[] i8042_interrupt+0x1dd/0x1ef

[] handle_IRQ_event+0x23/0x49

[] __do_IRQ+0x84/0xd6

[] do_IRQ+0x93/0xae

[] common_interrupt+0x1a/0x20

[] default_idle+0x0/0x59

[] default_idle+0x31/0x59

[] cpu_idle+0x9f/0xb9

[] start_kernel+0x379/0x380

=======================

CPU1:

c14a1f40 00000000 00000000 00000000 00000000 c0406531 c062ccf1 c0650e94

00000000 00000000 c053a221 c0641b83 00000001 c0417b4c 00000001 c040599b

00000001 c0403b98 c14a1000 00000000 00000000 00000000 00000000 0000007b

Call Trace:

[] show_stack+0x20/0x25

[] showacpu+0x27/0x32

[] smp_call_function_interrupt+0x39/0x52

[] call_function_interrupt+0x1f/0x24

[] default_idle+0x0/0x59

[] default_idle+0x31/0x59

[] cpu_idle+0x9f/0xb9

=======================

該操作顯示了每 CPU 的寄存器上下文和程序調用棧回溯信息。

其它功能鍵組合

H - 幫助

SysRq : HELP : loglevel0-8 reBoot Crashdump tErm Full kIll saK showMem

Nice powerOff showPc unRaw Sync showTasks Unmount shoWcpus

它顯示了當前系統支持的所有 SysRq 組合，所有的按鍵均用大寫字母表示。

0-8 - 更改 console_loglevel

SysRq : Changing Loglevel

Loglevel set to 6

上面是 SysRq-6 的輸出，它等同于 echo "6" > /proc/sys/kernel/printk 操作，將 console_loglevel 設置為 6 。

C - 觸發 Crashdump

SysRq : Trigger a crashdump

Kexec: Warning: crash image not loaded

Kernel panic - not syncing: SysRq-triggered panic!

在大多數情況下，我們通過前面的方法即可完成對系統掛起的基本診斷和數據收集。但是在一些特殊情況下，我們仍然需要一份完整的 crashdump 。畢竟 crashdump 包含比 SysRq – MPT 更多的信息，以利用后期做故障分析。

N - 降低實時任務運行優化級

SysRq : Nice All RT Tasks

這對于由實時任務消耗 CPU 引起的系統掛起會起到立竿見影的作用。

O - 關機

SysRq : Power Off

該操作會立即關機，一般很少使用。在必要的情況下，也推薦跟隨 S – U 一起使用。

結束語

SysRq 的處理機制可圈可點，它能夠在系統處于極端環境時響應按鍵并完成相應的處理。這在大多數時候有用，但也不是絕對的。一種情況是由于磁盤故障 syslogd 可能不再會往磁盤回寫 log，因此 SysRq 輸出將得不到記錄。即使配置了 netconsole，如果恰好是網絡相關功能出現錯誤時，也可能導致 SysRq 輸出不可記錄。相比之下，將服務器串口終端打開并用軟件記錄輸出的方式雖然原始，但也相對保險。無論如何，SysRq 已經在大多數情況下幫到大忙了。

筆者認為，SysRq 在處理系統掛起時安全重啟方面已經比較完善了。但是在提供故障診斷方面還有可待改進的地方。通過現有的 M-P-T 等信息，很難判斷每一次系統掛起的真正原因。現實世界的信息總是綜合多變的，如果能夠提供包括網絡 I/O，磁盤 I/O，進程的 CPU 及內存使用情況等等與性能方面的數據，雖然會產生一定的開銷，但對于系統掛起時的故障分析來講，是利大于弊的。

本文的下篇將講述如何擴展自定義的 SysRq 請求，以便在系統掛起時獲取更為豐富的診斷信息，通過這些信息來判斷系統掛起的原因，并快速準確的化解它們。

總結

以上是生活随笔為你收集整理的在服务器上一按l键自动退出,利用 SysRq 键排除和诊断系统故障的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。