真正的核心问题是比较罕见的，但它们确实存在。 Linux内核本身非常稳定，这主要是由于新的内核版本发布前进行了全面的测试。但你仍然会碰到麻烦，例如，您尝试加载一个不是由内核开发支持的封闭源代码模块。 当一个核心问题出现在功能机上时，机器将出现冻结并且不会响应。
如果发生这种情况，第一步是要找到什么被挂出来。有两种不同类型的挂起：中断挂起和非中断挂起。按Caps Lock键来找到它是哪种类型。如果大写锁定灯开关打开或关闭，这属于中断挂起，这是个好消息，因为它可以让你有一些选择。
如果没有，就属于非中断挂起。 当属于中断挂起时最好转储堆栈跟踪负责的程序。通过分析这样的……
我们一直都在努力坚持原创.......请不要一声不吭，就悄悄拿走。
我原创，你原创，我们的内容世界才会更加精彩！
【所有原创内容版权均属TechTarget，欢迎大家转发分享。但未经授权，严禁任何媒体（平面媒体、网络媒体、自媒体等）以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
真正的核心问题是比较罕见的，但它们确实存在。 Linux内核本身非常稳定，这主要是由于新的内核版本发布前进行了全面的测试。但你仍然会碰到麻烦，例如，您尝试加载一个不是由内核开发支持的封闭源代码模块。
当一个核心问题出现在功能机上时，机器将出现冻结并且不会响应。如果发生这种情况，第一步是要找到什么被挂出来。有两种不同类型的挂起：中断挂起和非中断挂起。按Caps Lock键来找到它是哪种类型。如果大写锁定灯开关打开或关闭，这属于中断挂起，这是个好消息，因为它可以让你有一些选择。如果没有，就属于非中断挂起。
当属于中断挂起时最好转储堆栈跟踪负责的程序。通过分析这样的堆栈跟踪，您的支持团队可能有能力找出到底发生了什么事。要做到这一点，你必须启用Magic SysRq功能。此功能允许使用几个能获得堆栈跟踪的关键序列的使用。要查看是否已启用，查看文件/proc/sys/kernel/sysrq。如果启用，它的值为1。如果没有启用，它的值为0。如果它被禁用，输入/ etc / sysctl.conf中并重新启动服务器，以确保sysrq是默认启用：
kernel.sysrq=1
如果发生中断挂起，使用"Alt+Print Screen+t"键告诉你的系统转储堆栈跟踪。堆栈跟踪将被写入系统日志，这样你就可以安全地重新启动，并从那里读取它。清单1给出了堆栈跟踪例子：
清单1：一个堆栈跟踪可以帮助您排除中断挂起的故障
[ 1451.314592] [] do_ioctl+0x78/0x90
[ 1451.314596] [] vfs_ioctl+0x22e/0x2b0
[ 1451.314599] [] rwsem_wake+0x4d/0x110
[ 1451.314603] [] sys_ioctl+0x56/0x70
[ 1451.314607] [] sysenter_past_esp+0x6b/0xa1
[ 1451.314616] =======================
[ 1451.314617] console-kit-d S f3ddbde8 0 6784 1
[ 1451.314619] f3d64b80 00000086 00000002 f3ddbde8 f3ddbde0 00000000 c04980e0 c049b480
[ 1451.314623] c049b480 c049b480 f3ddbdec f3d64cc4 c35a3480 ffffd253 00000000 000000ff
[ 1451.314626] 00000000 00000000 00000000 0000003a 00000001 c35aa000 00005607 c027858a
[ 1451.314630] Call Trace:
[ 1451.314640] [] vt_waitactive+0x5a/0xb0
[ 1451.314643] [] default_wake_function+0x0/0x10
...
[ 1451.314123] .jiffies : 114039
[ 1451.314124] .next_balance : 0.114020
[ 1451.314126] .curr->pid : 0
[ 1451.314127] .clock : 247950.082330
[ 1451.314128] .idle_clock : 0.000000
[ 1451.314140] .prev_clock_raw : 1451264.185399
[ 1451.314141] .clock_warps : 0
[ 1451.314142] .clock_overflows : 92068
[ 1451.314143] .clock_deep_idle_events : 0
[ 1451.314145] .clock_max_delta : 9.999478
[ 1451.314146] .cpu_load[0] : 0
[ 1451.314147] .cpu_load[1] : 0
[ 1451.314148] .cpu_load[2] : 0
[ 1451.314149] .cpu_load[3] : 0
[ 1451.314140] .cpu_load[4] : 0
[ 1451.314141]
[ 1451.314141] cfs_rq
[ 1451.314142] .exec_clock : 0.000000
[ 1451.314143] .MIN_vruntime : 0.000001
[ 1451.314145] .min_vruntime : 9571.283382
[ 1451.314146] .max_vruntime : 0.000001
[ 1451.314147] .spread : 0.000000
[ 1451.314149] .spread0 : -3276.906118
[ 1451.314150] .nr_running : 0
[ 1451.314151] .load : 0
[ 1451.314152] .nr_spread_over : 0
[ 1451.314153]
[ 1451.314153] cfs_rq
[ 1451.314154] .exec_clock : 0.000000
[ 1451.314156] .MIN_vruntime : 0.000001
[ 1451.314157] .min_vruntime : 9571.283382
[ 1451.314158] .max_vruntime : 0.000001
[ 1451.314160] .spread : 0.000000
[ 1451.314161] .spread0 : -3276.906118
[ 1451.314162] .nr_running : 0
[ 1451.314163] .load : 0
[ 1451.314164] .nr_spread_over : 0
[ 1451.314166]
[ 1451.314166] runnable tasks:
[ 1451.314167] task PID tree-key switches prio exec-runtime sum-exec sum-sleep
[ 1451.314168] -----------------------------------------------------------------------------------
[ 1451.314172]
做这个堆栈跟踪最好是找到排除这种故障的专门组织。你自己做就需要大量的C编程语言的知识，并且这远远超出了本文的范围。你的Linux分销商背后支持的公司应该能够找到有问题的进程或内核模块，并告诉你为什么它造成系统挂起。
在许多情况下，系统挂起是由污染或不支持的内核模块造成的。很容易发现你的内核是否受到污染：在cat / proc / sys/kernel / 行将返回值1。许多来自商业机构的内核模块，，并且不使用GPL协议，被认为是污染的模块。尽量避免这样的模块，并使用开源模块代替。
如果属于中断挂起，那很幸运，因为可返回的堆栈跟踪转储对支持组织来说足够了。在您的服务器上完全不响应的一个挂起使它很难获得调试信息。如果您的系统经常这样挂起，你可以强迫你的内核产生警告，并且转储它的堆栈跟踪到标准输出设备。要获得此，当它随GRUB启动时，你需要通过引导选项nmi_watchdog到内核。这将每隔5秒钟轮巡你的CPU。如果CPU响应了，没有任何事发生。如果没有响应，NMI处理程序的内核组件将产生警告并转储道标准输出设备。要获得这些信息，将串行控制台连接到您的服务器非常有用。请注意，您开始用nmi_watchdog选项的内核对性能不怎么好。在万不得已的情况下这样做。
如果非中断挂起直到添加了新硬件才发生，它很可能是由硬件引起的。尝试不用这些硬件配置你的服务器以避免这些问题。
现在，你知道如何区分发生在Linux上不同种类的挂起，同时也知道了如何在这种情况下调试信息。在本系列的下一篇文章中，您将学习如何处理你文件系统的一些问题。