![]() |
级别: 初级 罗 布 (luobuu@gmail.com), 自由撰稿人 2009 年 8 月 06 日 本文从一次典型的系统挂起事件,引出 SysRq 键的用途。然后介绍了如何启用 SysRq,以及使用 SysRq 的两种方式。接着通过 SysRq 在不同场合的用途分别介绍了各个功能键的使用,并对每个功能键的样例输出做了简单分析。最后,笔者从自身角度对 SysRq 功能做了一个简单的评价,并提供了一部分参考资料,以便读者进一步了解 SysRq 。本文所有操作实例均在 RHEL5u2 x86/kernel 2.6.18-92 上进行,体系与内核的差异会对 SysRq 的信息收集和显示有少许影响,详情请参考内核文档中的 sysrq.txt 关于平台部分的描述。 你是否遇到服务器不能通过 SSH 登录,也不能通过本地终端登录,但是却能 ping 通,数字键盘锁还可以响应击键操作的情况?在这种情况下,你除了按下电源或复位键之外,还做过什么吗?你是否想过这种情况是可能恢复的呢?你是否想过收集更多的信息来定位这次系统挂起的原因呢?上述情况,可称之为“可中断的系统挂起”。换句话来讲,系统因为某种原因已经停止对大部分正常服务的响应,但是系统仍然可以响应键盘的按键中断请求。在这种情况下,一组称为 SysRq 的按键组合将发挥它的神奇作用。 SysRq 经常被称为 Magic System Request,它被定义为一系列按键组合。之所以说它神奇,是因为它在系统挂起,大多数服务已无法响应的情况下,还能通过按键组合来完成一系列预先定义的系统操作。通过它,不但可以在保证磁盘数据安全的情况下重启一台挂起的服务器,避免数据丢失和重启后长时间的文件系统检查,还可以收集包括系统内存使用,CPU 任务处理,进程运行状态等系统运行信息,甚至还可能在无需重启的情况下挽回一台已经停止响应的服务器。
要启用 SysRq 功能,首先必须确保内核已经加入 CONFIG_MAGIC_SYSRQ 支持。在现今 Linux 发行版中,无一例外的均已加入该功能的支持,验证如下:
SysRq 功能默认在 RHEL5u2 上是禁用的。可以通过 proc 文件系统来启用它。使用 sysctl 命令启用它,并通过 /proc 来检查其可用性。
kernel.sysrq 还可接受除 0 和 1 以外的启用参数,详情请参考 sysrq 内核文档。 通过把” kernel.sysrq = 1 ”设置到 /etc/sysctl.conf 中,可以使 SysRq 在下次系统重启后仍然生效。请注意,在非 RHEL 系统中,也许需要通过其它的配置文件来使之重启后生效。
网上有道题,问在只有 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 是为了查看服务器的 CPU,内存或进程信息。 SysRq 默认会输出到本地控制台终端,并写入 syslog,但这并不是个好主意。因为对于大多数系统挂起的情况,我们已经无法再访问这两个信息源,在无法判定系统故障的情况下,只好无奈的使用后面即将介绍的 R-E-I-S-U-B 序列来重启服务器。接下来将介绍 SysRq 输出的几种方法。只有最大程度的获取到 SysRq 输出,才能更好的利用 SysRq 提供的其它功能。 SysRq 默认会根据 console_loglevel 输出到本地终端。只要 console_loglevel 大于 default_message_loglevel,SysRq 信息就会输出到本地控制台终端。它在测试的时候都好用,但一到关键时刻,系统挂起无法切换,大量输出造成滚屏,以及信息无法记录等问题随之而来。 根据 syslog 的默认配置,SysRq 默认会记录到 /var/log/messages,并且这里记录的信息与 console_loglevel 无关,基本是完整的。但是由于负责记录日志的 syslogd 本身也是一个用户进程,在执行后面即将介绍的 SysRq-E, SysRq-I 时也会被终结,这就意味着 syslog 记录的信息在一定情况下将不再完整。同时由于系统挂起时查看 syslog 日志本身就是一件难上加难的事,这里记录的信息往往只能用在系统恢复过后的故障分析,对故障发生时的实时诊断并没有太大的帮助。 利用 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 序列是 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 模式
有关键盘工作模式,请参考资料中的 kbd_mode 手册。 E - 向除 init 以外所有进程发送 SIGTERM 信号
因为 syslogd 本身也被结束,所以 SysRq 也许不会被记录下来。但是查看 /var/log/messages 会看到类似下面的消息:
I - 向除 init 以外所有进程发送 SIGKILL 信号
与 E 类似,因为 syslogd 本身也被结束,除非 netconsole 或串口记录已打开,否则连上面的信息都无法捕捉。同时,因为 SIGKILL 是不可捕获的信号,/var/log/messages 里面也不会留下任何线索。 S - 磁盘缓冲区同步
该操作会把磁盘缓冲区的数据回写,以防止数据丢失,通常会有一定延时。在能看到输出的情况下,请等到 ” Emergency Sync complete ” 过后再继续后续操作。否则,等十秒钟左右,再进行后续 SysRq 操作。 U - 重新挂载为只读模式
该操作会把磁盘重挂载为只读模式,以防止数据的损坏。与 S 类似,该操作通常也有一定延时。请等到 ” Emergency Remount complete ” 出现过后再进行后续操作,或者等候十秒钟再进行后续 SysRq 操作。 B - 立即重启系统
该操作会立即重启系统,比想象中要快。 仅从系统挂起后安全重启来看,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 信号
I - 向所有进程发送 SIGKILL 信号
K - 结束与当前控制台相关的全部进程
该操作结束了文本控制台下正在运行的 top 程序,以及登录的 shell 。 F - 人为触发 OOM Killer
该操作人为触发 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 - 打印内存使用信息
该操作显示了 cpu 相关分区信息,全局页使用情况,分区页使用情况,分区 slab 使用情况,页缓存使用情况,swap 使用情况等等。 P - 打印当前 CPU 寄存器信息
该操作显示了正在执行的进程名,运行函数,寄存器上下文,以及程序的调用栈回溯等信息。这对于分析死锁引起的系统挂起有着非常重要的作用。一般来说我们会多采几次重复样本,以便更加准确的做出系统运行状态的判断。 T - 打印进程列表
该操作显示了进程列表,包含各进程的名称,进程 PID,父 PID 及兄弟 PID 等相关信息,以及进程的运行状态。对于正在运行中的进程(R),没有太多的信息。对于处于睡眠状态的进程,列出其调用栈回溯信息,以便进行调试跟踪。由于篇幅关系,去掉了大部分冗余的信息。 W - 打印 CPU 信息
该操作显示了每 CPU 的寄存器上下文和程序调用栈回溯信息。 H - 帮助
它显示了当前系统支持的所有 SysRq 组合,所有的按键均用大写字母表示。 0-8 - 更改 console_loglevel
上面是 SysRq-6 的输出,它等同于 echo "6" > /proc/sys/kernel/printk 操作,将 console_loglevel 设置为 6 。 C - 触发 Crashdump
在大多数情况下,我们通过前面的方法即可完成对系统挂起的基本诊断和数据收集。但是在一些特殊情况下,我们仍然需要一份完整的 crashdump 。毕竟 crashdump 包含比 SysRq – MPT 更多的信息,以利用后期做故障分析。 N - 降低实时任务运行优化级
这对于由实时任务消耗 CPU 引起的系统挂起会起到立竿见影的作用。 O - 关机
该操作会立即关机,一般很少使用。在必要的情况下,也推荐跟随 S – U 一起使用。
SysRq 的处理机制可圈可点,它能够在系统处于极端环境时响应按键并完成相应的处理。这在大多数时候有用,但也不是绝对的。一种情况是由于磁盘故障 syslogd 可能不再会往磁盘回写 log,因此 SysRq 输出将得不到记录。即使配置了 netconsole,如果恰好是网络相关功能出现错误时,也可能导致 SysRq 输出不可记录。相比之下,将服务器串口终端打开并用软件记录输出的方式虽然原始,但也相对保险。无论如何,SysRq 已经在大多数情况下帮到大忙了。 笔者认为,SysRq 在处理系统挂起时安全重启方面已经比较完善了。但是在提供故障诊断方面还有可待改进的地方。通过现有的 M-P-T 等信息,很难判断每一次系统挂起的真正原因。现实世界的信息总是综合多变的,如果能够提供包括网络 I/O,磁盘 I/O,进程的 CPU 及内存使用情况等等与性能方面的数据,虽然会产生一定的开销,但对于系统挂起时的故障分析来讲,是利大于弊的。 本文的下篇将讲述如何扩展自定义的 SysRq 请求,以便在系统挂起时获取更为丰富的诊断信息,通过这些信息来判断系统挂起的原因,并快速准确的化解它们。
|
联系客服