Ошибка в kernel в линуксе

Kernel Panics

A kernel panic occurs when the Linux kernel enters an unrecoverable failure state. The state typically originates from buggy hardware drivers resulting in the machine being deadlocked, non-responsive, and requiring a reboot. Just prior to deadlock, a diagnostic message is generated, consisting of: the machine state when the failure ocurred, a call trace leading to the kernel function that recognized the failure, and a listing of currently loaded modules. Thankfully, kernel panics don’t happen very often using mainline versions of the kernel—such as those supplied by the official repositories—but when they do happen, you need to know how to deal with them.

Note: Kernel panics are sometimes referred to as oops or kernel oops. While both panics and oops occur as the result of a failure state, an oops is more general in that it does not necessarily result in a deadlocked machine—sometimes the kernel can recover from an oops by killing the offending task and carrying on.

Tip: Pass the kernel parameter oops=panic at boot or write 1 to /proc/sys/kernel/panic_on_oops to force a recoverable oops to issue a panic instead. This is advisable is you are concerned about the small chance of system instability resulting from an oops recovery which may make future errors difficult to diagnose.

Examine panic message

If a kernel panic occurs very early in the boot process, you may see a message on the console containing «Kernel panic — not syncing:», but once Systemd is running, kernel messages will typically be captured and written to the system log. However, when a panic occurs, the diagnostic message output by the kernel is almost never written to the log file on disk because the machine deadlocks before system-journald gets the chance. Therefore, the only way to examine the panic message is to view it on the console as it happens (without resorting to setting up a kdump crashkernel). You can do this by booting with the following kernel parameters and attempting to reproduce the panic on tty1:

systemd.journald.forward_to_console=1 console=tty1

Tip: In the event that the panic message scrolls away too quickly to examine, try passing the kernel parameter pause_on_oops=seconds at boot.

Example scenario: bad module

It is possible to make a best guess as to what subsystem or module is causing the panic using the information in the diagnostic message. In this scenario, we have a panic on some imaginary machine during boot. Pay attention to the lines highlighted in bold:

kernel: BUG: unable to handle kernel NULL pointer dereference at (null) [1]
kernel: IP: fw_core_init+0x18/0x1000 [firewire_core] [2]
kernel: PGD 718d00067 
kernel: P4D 718d00067 
kernel: PUD 7b3611067 
kernel: PMD 0 
kernel: 
kernel: Oops: 0002 [#1] PREEMPT SMP
kernel: Modules linked in: firewire_core(+) crc_itu_t cfg80211 rfkill ipt_REJECT nf_reject_ipv4 nf_log_ipv4 nf_log_common xt_LOG nf_conntrack_ipv4 ... [3] 
kernel: CPU: 6 PID: 1438 Comm: modprobe Tainted: P           O    4.13.3-1-ARCH #1
kernel: Hardware name: Gigabyte Technology Co., Ltd. H97-D3H/H97-D3H-CF, BIOS F5 06/26/2014
kernel: task: ffff9c667abd9e00 task.stack: ffffb53b8db34000
kernel: RIP: 0010:fw_core_init+0x18/0x1000 [firewire_core]
kernel: RSP: 0018:ffffb53b8db37c68 EFLAGS: 00010246
kernel: RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
kernel: RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffffc16d3af4
kernel: RBP: ffffb53b8db37c70 R08: 0000000000000000 R09: ffffffffae113e95
kernel: R10: ffffe93edfdb9680 R11: 0000000000000000 R12: ffffffffc16d9000
kernel: R13: ffff9c6729bf8f60 R14: ffffffffc16d5710 R15: ffff9c6736e55840
kernel: FS:  00007f301fc80b80(0000) GS:ffff9c675dd80000(0000) knlGS:0000000000000000
kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: 0000000000000000 CR3: 00000007c6456000 CR4: 00000000001406e0
kernel: Call Trace:
kernel:  do_one_initcall+0x50/0x190 [4]
kernel:  ? do_init_module+0x27/0x1f2
kernel:  do_init_module+0x5f/0x1f2
kernel:  load_module+0x23f3/0x2be0
kernel:  SYSC_init_module+0x16b/0x1a0
kernel:  ? SYSC_init_module+0x16b/0x1a0
kernel:  SyS_init_module+0xe/0x10
kernel:  entry_SYSCALL_64_fastpath+0x1a/0xa5
kernel: RIP: 0033:0x7f301f3a2a0a
kernel: RSP: 002b:00007ffcabbd1998 EFLAGS: 00000246 ORIG_RAX: 00000000000000af
kernel: RAX: ffffffffffffffda RBX: 0000000000c85a48 RCX: 00007f301f3a2a0a
kernel: RDX: 000000000041aada RSI: 000000000001a738 RDI: 00007f301e7eb010
kernel: RBP: 0000000000c8a520 R08: 0000000000000001 R09: 0000000000000085
kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000c79208
kernel: R13: 0000000000c8b4d8 R14: 00007f301e7fffff R15: 0000000000000030
kernel: Code: <c7> 04 25 00 00 00 00 01 00 00 00 bb f4 ff ff ff e8 73 43 9c ec 48 
kernel: RIP: fw_core_init+0x18/0x1000 [firewire_core] RSP: ffffb53b8db37c68
kernel: CR2: 0000000000000000
kernel: ---[ end trace 71f4306ea1238f17 ]---
kernel: Kernel panic - not syncing: Fatal exception [5]
kernel: Kernel Offset: 0x80000000 from 0xffffffff810000000 (relocation range: 0xffffffff800000000-0xfffffffffbffffffff
kernel: ---[ end Kernel panic - not syncing: Fatal exception

• [1] Indicates the type of error that caused the panic. In this case it was a programmer bug.
• [2] Indicates that the panic happened in a function called fw_core_init in module firewire_core.
• [3] Indicates that firewire_core was the latest module to be loaded.
• [4] Indicates that the function that called function fw_core_init was do_one_initcall.
• [5] Indicates that this oops message is, in fact, a kernel panic and the system is now deadlocked.

We can surmise then, that the panic occurred during the initialization routine of module firewire_core as it was loaded. (We might assume then, that the machine’s firewire hardware is incompatible with this version of the firewire driver module due to a programmer error, and will have to wait for a new release.) In the meantime, the easiest way to get the machine running again is to prevent the module from being loaded. We can do this in one of two ways:

• If the module is being loaded during the execution of the initramfs, reboot with the kernel parameter rd.blacklist=firewire_core.
• Otherwise reboot with the kernel parameter module_blacklist=firewire_core.

Reboot into root shell and fix problem

You’ll need a root shell to make changes to the system so the panic no longer occurs. If the panic occurs on boot, there are several strategies to obtain a root shell before the machine deadlocks:

• Reboot with the kernel parameter emergency, rd.emergency, or -b to receive a prompt to login just after the root filesystem is mounted and systemd is started.

Note: At this point, the root filesystem will be mounted read-only. Execute # mount -o remount,rw / to make changes.

• Reboot with the kernel parameter rescue, rd.rescue, single, s, S, or 1 to receive a prompt to login just after local filesystems are mounted.
• Reboot with the kernel parameter systemd.debug-shell=1 to obtain a very early root shell on tty9. Switch to it with by pressing Ctrl-Alt-F9.
• Experiment by rebooting with different sets of kernel parameters to possibly disable the kernel feature that is causing the panic. Try the «old standbys» acpi=off and nolapic.

Tip: See Documentation/admin-guide/kernel-parameters.txt in the Linux kernel source tree for all options.

• As a last resort, boot with the Arch Linux Installation CD and mount the root filesystem on /mnt then execute # arch-chroot /mnt.

Disable the service or program that is causing the panic, roll-back a faulty update, or fix a configuration problem.

1 Question at a time per the FAQ

1. What is kernel panic?
   When the kernel can’t load properly or «freaks out» and fails to boot properly or crashes(see edit credit at the bottom).

2. Why it occurs?
   Hosed updates, failing hardware, unsupported hardware, failed or missing drive or partition (see edit credit at the bottom)

3. How can I understand kernel panic occurred?
   Watch boot prompts(turn off quiet kernel parameter) OR your machine fails to boot

4. What effect it has on system?
   Failure to boot or system crash

5. Does it only occur in Linux?
   No, all unix-like operating systems can have kernel panics. It’s the equivalent of a Windows Blue Screen of Death

6. How can I prevent it?
   It normally doesn’t happen. Test updates and troubleshoot the problem. Use stable instead of development branches.

Additional note: Kernel panic and system failure/shutdown can be directly responsible for protecting your computer from physical damage. Examples include halting before extreme overheating or disk corruption. See edit credits at the bottom for direct quote.

edits

Per B. Roland Missing or corrupted disks or volumes can cause this as well.
(Good point and I overlooked it)

Per Kees Kernel panic can also occur while running.
note: Can happen when a function fails sort of gracefully inside the kernel, but most often happens during module or kernel loading(which is usually during boot). I thought I touched on it at «during boot or system crash», but I see how my answer to (1) stated it only occurs during boot.

Per rafalcieslak direct quote — ‘There is one very important thing that must be added: The main point in the whole kernel panic is to protect your computer. The kernel freezes not only because it failed to do something, but also in order to prevent your computer from f.e. overheating, hard drives corruption, and any other hardware problems, that may occur, if some incorrect orders are executed, of a module (for example a module responsible for controlling the fan) failed to load, etc. This is why the kernel prefers to freeze, than to overcome the problem.’

Хотя в современных Linux-системах ядро отличается достаточно высоким уровнем стабильности, вероятность серьезных системных ошибок, тем не менее, имеется всегда. Когда происходит неисправимая ошибка, имеет место состояние, называемое паникой ядра (kernel panic): стандартный обработчик выводит на экран информацию, которая должна помочь в устранении неисправности, и входит в бесконечный цикл.

Для диагностики и анализа причин сбоев ядра разработчиками компании RedHat был разработан специализированный инструмент — kdump. Принцип его работы можно кратко описать следующим образом. Создается два ядра: основное и аварийное (именно оно используется для сбора дампа памяти). При загрузке основного ядра под аварийное ядро выделяется определенный размер памяти. При помощи kexec во время паники основного ядра загружается аварийное и собирает дамп.

В этой статье мы подробно расскажем о том, как конфигурировать kdump и анализировать с его помощью системные ошибки. Мы рассмотрим особенности работы с kdump в OC Ubuntu; в других дистрибутивах процедуры настройки и конфигурирования kdump существенно отличаются.

Установка и настройка kdump

Установим kdump с помощью команды

$ sudo apt-get install linux-crashdump kdump-tools

Настройки kdump хранятся в конфигурационном файле /etc/default/kdump-tools

# kdump-tools configuration
# ---------------------------------------------------------------------------
# USE_KDUMP - controls kdump will be configured
#     0 - kdump kernel will not be loaded
#     1 - kdump kernel will be loaded and kdump is configured
# KDUMP_SYSCTL - controls when a panic occurs, using the sysctl
#     interface.  The contents of this variable should be the
#     "variable=value ..." portion of the 'sysctl -w ' command.
#     If not set, the default value "kernel.panic_on_oops=1" will
#     be used.  Disable this feature by setting KDUMP_SYSCTL=" "
#     Example - also panic on oom:
#         KDUMP_SYSCTL="kernel.panic_on_oops=1 vm.panic_on_oom=1"
#
USE_KDUMP=1
# KDUMP_SYSCTL="kernel.panic_on_oops=1"

Чтобы активировать kdump, отредактируем этот файл и установим значение параметра USE_KDUMP=1.
Также в конфигурационном файле содержатся следующие параметры:

• KDUMP_KERNEL — полный путь к аварийному ядру;
• KDUMP_INITRD — полный путь к initrd аварийного ядра;
• KDUMP_CORE — указывает, где будет сохранен файл дампа ядра. По умолчанию дамп сохраняется в директории /var/crash (KDUMP_CORE=/var/crash);
• KDUMP_FAIL_CMD — указывает, какое действие нужно совершить в случае ошибки при сохранении дампа (по умолчанию будет выполнена команда reboot -f);
• DEBUG_KERNEL — отладочная версия работающего ядра. По умолчанию используются /usr/lib/debug/vmlinux-$. Если значение этого параметра не установлено, утилита makedumpfile создаст только дамп всех страниц памяти;
• MAKEDUMP_ARGS — содержит дополнительные аргументы, передаваемые утилите makedumpfile. По умолчанию этот параметр имеет значение ‘-c -d 31’, указывающую, что необходимо использовать сжатие и включать в дамп только используемые страницы ядра.

Установив все необходимые параметры, выполним команду update-grub и выберем install the package maintainer’s version.

Затем перезагрузим систему и убедимся в том, что kdump готов к работе:

$ cat/proc/cmdline

BOOT_IMAGE=/boot/vmlinuz-3.8.0-35-generic root=UUID=bb2ba5e1-48e1-4829-b565-611542b96018 ro crashkernel=384 -:128M quiet splash vt.handoff=7

Обратим особое внимание на параметр crashkernel=384 -:128M. Он означает, что аварийное ядро будет использовать 128 Мб памяти при загрузке. Можно прописать в grub параметр crashkernel = auto: в этом случае память под аварийное ядро будет выделяться автоматически.

Для того, чтобы мы могли анализировать дамп с помощью утилиты crash, нам понадобится также файл vmlinux, содержащий отладочную информацию:

$ sudo tee /etc/apt/sources.list.d/ddebs.list << EOF
deb http://ddebs.ubuntu.com/ $(lsb_release -cs)          main restricted universe multiverse
deb http://ddebs.ubuntu.com/ $(lsb_release -cs)-security main restricted universe multiverse
deb http://ddebs.ubuntu.com/ $(lsb_release -cs)-updates  main restricted universe multiverse
deb http://ddebs.ubuntu.com/ $(lsb_release -cs)-proposed main restricted universe multiverse
EOF
$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys ECDCAD72428D7C01
$ sudo apt-get update
$ sudo apt-get install linux-image-$(uname -r)-dbgsym

По завершении установки еще раз проверим статус kdump:

$ kdump-config status

Если kdump находится в рабочем состоянии, на консоль будет выведено следующее сообщение:

current state: ready to kdump

Тестируем kdump

Вызовем панику ядра при помощи следующих команд:

echo c | sudo tee /proc/sysrq-trigger

В результате их выполнения система «зависнет».

После этого в течение нескольких минут будет создан дамп, который будет доступен в директории /var/crash после перезагрузки.

Информацию о сбое ядра можно просмотреть с помощью утилиты crash:

$ sudo crash /usr/lib/debug/boot/vmlinux-3.13.0-24-generic /var/crash/201405051934/dump.201405051934
crash 7.0.3
Copyright (C) 2002-2013  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.

GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...

      KERNEL: /usr/lib/debug/boot/vmlinux-3.13.0-24-generic
    DUMPFILE: /var/crash/201405051934/dump.201405051934  [PARTIAL DUMP]
        CPUS: 4
        DATE: Mon May  5 19:34:38 2014
      UPTIME: 00:54:46
LOAD AVERAGE: 0.14, 0.07, 0.05
       TASKS: 495
    NODENAME: Ubuntu
     RELEASE: 3.13.0-24-generic
     VERSION: #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014
     MACHINE: x86_64  (2675 Mhz)
      MEMORY: 8 GB
       PANIC: "Oops: 0002 [#1] SMP " (check log for details)
         PID: 7826
     COMMAND: "tee"
        TASK: ffff8800a2ef8000  [THREAD_INFO: ffff8800a2e68000]
         CPU: 2
       STATE: TASK_RUNNING (PANIC)

crash>

На основе приведенного вывода мы можем заключить, что системному сбою предшествовало событие «Oops: 0002 [#1] SMP», произошедшее на CPU2 при выполнении команды tee.
Утилита crash обладает также широким спектром возможностей для диагностики причин краха ядра. Рассмотрим их более подробно.

Диагностика причин сбоя с помощью утилиты crash

Crash сохраняет информацию обо всех системных событиях, предшествовавших краху ядра. С ее помощью можно воссоздать состояние системы на момент сбоя: узнать, какие процессы были запущены на момент краха, какие файлы открыты и т.п. Эта информация помогает поставить точный диагноз и предупредить крахи ядра в будущем.

В утилите crash имеется свой набор команд:

$ crash> help
*              files          mach           repeat         timer          
alias          foreach        mod            runq           tree           
ascii          fuser          mount          search         union          
bt             gdb            net            set            vm             
btop           help           p              sig            vtop           
dev            ipcs           ps             struct         waitq          
dis            irq            pte            swap           whatis         
eval           kmem           ptob           sym            wr             
exit           list           ptov           sys            q              
extend         log            rd             task           

crash version: 7.0.3    gdb version: 7.6
For help on any command above, enter "help <command>".
For help on input options, enter "help input".
For help on output options, enter "help output".

crash>

Для каждой этой команды можно вызвать краткий мануал, например:

crash> help set

Все команды мы описывать не будем (с детальной информацией можно ознакомиться в официальном руководстве пользователя от компании RedHat), а расскажем лишь о наиболее важных из них.

В первую очередь следует обратить внимание на команду bt (аббревиатура от backtrace — обратная трассировка). С ее помощью можно посмотреть детальную информацию о содержании памяти ядра (подробности и примеры использования см. здесь). Однако во многих случаях для определения причины системного сбоя бывает вполне достаточно команды log, выводящее на экран содержимое буфера сообщений ядра в хронологическом порядке.

Приведем фрагмент ее вывода:

[ 3288.251955] CPU: 2 PID: 7826 Comm: tee Tainted: PF          O 3.13.0-24-generic #46-Ubuntu
[ 3288.251957] Hardware name: System manufacturer System Product Name/P7P55D LE, BIOS 2003    12/16/2010
[ 3288.251958] task: ffff8800a2ef8000 ti: ffff8800a2e68000 task.ti: ffff8800a2e68000
[ 3288.251960] RIP: 0010:[<ffffffff8144de76>]  [<ffffffff8144de76>] sysrq_handle_crash+0x16/0x20
[ 3288.251963] RSP: 0018:ffff8800a2e69e88  EFLAGS: 00010082
[ 3288.251964] RAX: 000000000000000f RBX: ffffffff81c9f6a0 RCX: 0000000000000000
[ 3288.251965] RDX: ffff88021fc4ffe0 RSI: ffff88021fc4e3c8 RDI: 0000000000000063
[ 3288.251966] RBP: ffff8800a2e69e88 R08: 0000000000000096 R09: 0000000000000387
[ 3288.251968] R10: 0000000000000386 R11: 0000000000000003 R12: 0000000000000063
[ 3288.251969] R13: 0000000000000246 R14: 0000000000000004 R15: 0000000000000000
[ 3288.251971] FS:  00007fb0f665b740(0000) GS:ffff88021fc40000(0000) knlGS:0000000000000000
[ 3288.251972] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 3288.251973] CR2: 0000000000000000 CR3: 00000000368fd000 CR4: 00000000000007e0
[ 3288.251974] Stack:
[ 3288.251975]  ffff8800a2e69ec0 ffffffff8144e5f2 0000000000000002 00007fff3cea3850
[ 3288.251978]  ffff8800a2e69f50 0000000000000002 0000000000000008 ffff8800a2e69ed8
[ 3288.251980]  ffffffff8144eaff ffff88021017a900 ffff8800a2e69ef8 ffffffff8121f52d
[ 3288.251983] Call Trace:
[ 3288.251986]  [<ffffffff8144e5f2>] __handle_sysrq+0xa2/0x170
[ 3288.251988]  [<ffffffff8144eaff>] write_sysrq_trigger+0x2f/0x40
[ 3288.251992]  [<ffffffff8121f52d>] proc_reg_write+0x3d/0x80
[ 3288.251996]  [<ffffffff811b9534>] vfs_write+0xb4/0x1f0
[ 3288.251998]  [<ffffffff811b9f69>] SyS_write+0x49/0xa0
[ 3288.252001]  [<ffffffff8172663f>] tracesys+0xe1/0xe6
[ 3288.252002] Code: 65 34 75 e5 4c 89 ef e8 f9 f7 ff ff eb db 0f 1f 80 00 00 00 00 66 66 66 66 90 55 c7 05 94 68 a6 00 01 00 00 00 48 89 e5 0f ae f8 <c6> 04 25 00 00 00 00 01 5d c3 66 66 66 66 90 55 31 c0 c7 05 be 
[ 3288.252025] RIP  [<ffffffff8144de76>] sysrq_handle_crash+0x16/0x20
[ 3288.252028] RSP <ffff8800a2e69e88>
[ 3288.252029] CR2: 0000000000000000

В одной из строк вывода будет указано событие, вызвавшее системную ошибку:

[ 3288.251889] SysRq: Trigger a crash

С помощью команды ps можно вывести на экран список процессов, которые были запущены на момент сбоя:

crash> ps
   PID    PPID  CPU       TASK        ST  %MEM     VSZ    RSS  COMM
      0      0   0  ffffffff81a8d020  RU   0.0       0      0  [swapper]
      1      0   0  ffff88013e7db500  IN   0.0   19356   1544  init
      2      0   0  ffff88013e7daaa0  IN   0.0       0      0  [kthreadd]
      3      2   0  ffff88013e7da040  IN   0.0       0      0  [migration/0]
      4      2   0  ffff88013e7e9540  IN   0.0       0      0  [ksoftirqd/0]
      7      2   0  ffff88013dc19500  IN   0.0       0      0  [events/0]

Для просмотра информации об использовании виртуальной памяти используется команда vm:

crash> vm
PID: 5210   TASK: ffff8801396f6aa0  CPU: 0   COMMAND: "bash"
       MM              		 PGD          RSS    TOTAL_VM
ffff88013975d880  ffff88013a0c5000  1808k   108340k
      VMA           START       END     FLAGS FILE
ffff88013a0c4ed0     400000     4d4000 8001875 /bin/bash
ffff88013cd63210 3804800000 3804820000 8000875 /lib64/ld-2.12.so
ffff880138cf8ed0 3804c00000 3804c02000 8000075 /lib64/libdl-2.12.so

Команда swap выведет на консоль информацию об использовании области подкачки:

crash> swap
FILENAME           TYPE         SIZE      USED   PCT  PRIORITY
/dm-1            PARTITION    2064376k       0k   0%     -1

Информацию о прерываниях CPU можно просмотреть с помощью команды irq:

crash> irq -s
           CPU0
  0:        149  IO-APIC-edge     timer
  1:        453  IO-APIC-edge     i8042
  7:          0  IO-APIC-edge     parport0
  8:          0  IO-APIC-edge     rtc0
  9:          0  IO-APIC-fasteoi  acpi
 12:        111  IO-APIC-edge     i8042
 14:        108  IO-APIC-edge     ata_piix

Вывести на консоль список файлов, открытых на момент сбоя, можно с помощью команды files:

crash> files
PID: 5210   TASK: ffff8801396f6aa0  CPU: 0   COMMAND: "bash"
ROOT: /    CWD: /root
 FD       FILE            DENTRY           INODE       TYPE PATH
  0 ffff88013cf76d40 ffff88013a836480 ffff880139b70d48 CHR  /tty1
  1 ffff88013c4a5d80 ffff88013c90a440 ffff880135992308 REG  /proc/sysrq-trigger
255 ffff88013cf76d40 ffff88013a836480 ffff880139b70d48 CHR  /tty1

Наконец, получить в сжатом виде информацию об общем состоянии системы можно с помощью команды sys:

crash> sys
      KERNEL: /usr/lib/debug/lib/modules/2.6.32-431.5.1.el6.x86_64/vmlinux
    DUMPFILE: /var/crash/127.0.0.1-2014-03-26-12:24:39/vmcore  [PARTIAL DUMP]
        CPUS: 1
        DATE: Wed Mar 26 12:24:36 2014
      UPTIME: 00:01:32
LOAD AVERAGE: 0.17, 0.09, 0.03
       TASKS: 159
    NODENAME: elserver1.abc.com
     RELEASE: 2.6.32-431.5.1.el6.x86_64
     VERSION: #1 SMP Fri Jan 10 14:46:43 EST 2014
     MACHINE: x86_64  (2132 Mhz)
      MEMORY: 4 GB
       PANIC: "Oops: 0002 [#1] SMP " (check log for details)

Заключение

Анализ и диагностика причин падения ядра представляет собой очень специфическую и сложную тему, которую невозможно уместить в рамки одной статьи. Мы еще вернемся к ней в следующих публикациях.

Для желающих узнать больше — несколько полезных ссылок:

• Документация kdump на сайте kernel.org
• Книга, целиком посвященная проблемам диагностики сбоев ядра
• Подробная документация для утилиты crash

Читателей, которые не могут оставлять комментарии здесь, приглашаем к нам в блог.