接触
SysRq
完全是一种巧合。由于平时手比较欠,总是冷不丁地就将ubuntu
给整死机了,这要是在以前我大概是选择按下电源键重启了。但这样做的危害也是显而易见的,轻则数据丢失,重则系统直接挂掉重启一片黑。于是乎,我给自己告诫再三:死机切记不要暴力重启。
linux应对死机三步骤
经过多方查阅与实践总结,我大致摸索出了如下应对系统死机的解决方案,流程如下:
- 如果死机是由
xwindow
等窗口程序引起的,如因为gnome
导致的假死机,这时候可以按下alt+F2
调出gnome
运行窗口,接着输入r
回车,来刷新gnome
。 - 如果第一步不奏效,可能是
xwindow
已经挂掉了,这时候可以选择进入tty
终端。按下快捷键组合ctrl+alt+F3
就进入了tty3
(类似的还可以进入tty4
、tty5
等)。这是一个类似shell
的界面,在这里我们可以先通过top
命令获取高cpu
占用进程,再通过pkill 进程名
或者kill -9 pid
的方式杀死死锁进程。最后通过ctrl+alt+F2
返回xwindow
界面。 - 如果以上都无效,那大概率是系统定底层出现了问题,这时候就要祭出
SysRq
魔术键了。
什么是SysRq
SysRq
经常被称为 Magic System Request
,它被定义为一系列按键组合。当系统因为某种原因已经停止对大部分正常服务的响应,但是系统仍然可以响应键盘的按键中断请求。在这种情况下,SysRq
的按键组合将发挥它的神奇作用。
通过它,不但可以在保证磁盘数据安全的情况下重启一台挂起的服务器,避免数据丢失和重启后长时间的文件系统检查,还可以收集包括系统内存使用,CPU 任务处理,进程运行状态等系统运行信息,甚至还可能在无需重启的情况下挽回一台已经停止响应的服务器。
启动SysRq
首先检查SysRq
是否开启
1 | cat /proc/sys/kernel/sysrq |
若输出为0,则还未开启。可以通过systcl
命令开启SysRq
,命令如下:
1 | sudo sysctl -w kernel.sysrq=1 |
由于以上操作只在本次开机运行时有效,为保证下次开机SysRq
服务自动启用,需进行如下配置:
编辑/etc/sysctl.conf
,添加如下一行内容(或去掉其前注释)
1 | kernel.sysrq = 1 |
常用SysRq组合键
R-E-I-S-U-B
– 安全重启万精油
1 | R - 把键盘设置为 ASCII 模式 (用于接收后面键盘输入) |
由于系统环境与后台进程个数的不确定性,每一步按键操作执行完成所费时间无法确定。为保险起见,一般采用R – 1 秒 – E – 30 秒 – I – 10 秒 – S – 5 秒 – U – 5 秒 – B,而不是一气呵成地按下这六个键。
E-I-K
– 解决系统假死利器
有时候系统的死机仅仅是因为个别进程过分消耗cpu
或内存等系统资源所引发的,这时候就没有必要非得重启来解决问题。我们需要做的就是找出“幕后黑手”,结束掉该进程就行了。
1 | E - 向除 init 以外所有进程发送 SIGTERM 信号 (让进程自己正常退出) |
M-P-T-W
– 系统死机证据收集机
SysRq
提供了 M-P-T-W 序列,在恢复系统挂起之前,这是一个推荐执行的序列。它会记录下当前系统的内存使用情况,当前 CPU 寄存器的状态,进程运行状态,以及所有 CPU 及寄存器的状态。通过这些信息,可以对挂起的原因做粗略的分析。
1 | M - 打印内存使用信息 |
其它功能键组合
1 | H - 帮助 |
查看SysRq输出
输出到本地终端
SysRq
默认会根据console_loglevel
输出到本地终端。只要console_loglevel
大于default_message_loglevel
,SysRq
信息就会输出到本地控制台终端。输出到 syslog
根据
syslog
的默认配置,SysRq
默认会记录到/var/log/messages
,并且这里记录的信息与console_loglevel
无关,基本是完整的。但是由于负责记录日志的syslogd
本身也是一个用户进程,在执行后面即将介绍的SysRq-E
,SysRq-I
时也会被终结,这就意味着syslog
记录的信息在一定情况下将不再完整。通过 netconsole 输出
输出到串口终端
附录 – SysRq.txt
1 | Linux Magic System Request Key Hacks |