Kdump - діагностика і аналіз причин збоїв ядра

    Kdump
 
Хоча в сучасних 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 © 2002-2013 Red Hat, Inc.
Copyright © 2004, 2005, 2006, 2010 IBM Corporation
Copyright © 1999-2006 Hewlett-Packard Co
Copyright © 2005, 2006, 2011, 2012 Fujitsu Limited
Copyright © 2006, 2007 VA Linux Systems Japan KK
Copyright © 2005, 2011 NEC Corporation
Copyright © 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright © 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 © 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 +0 x16/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 +0 xa2/0x170
[3288.251988] [<ffffffff8144eaff>] write_sysrq_trigger +0 x2f/0x40
[3288.251992] [<ffffffff8121f52d>] proc_reg_write +0 x3d/0x80
[3288.251996] [<ffffffff811b9534>] vfs_write +0 xb4/0x1f0
[3288.251998] [<ffffffff811b9f69>] SyS_write +0 x49/0xa0
[3288.252001] [<ffffffff8172663f>] tracesys +0 xe1/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 +0 x16/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]
      2 Березня 0 ffff88013e7da040 IN 0.0 0 0 [migration / 0]
      4 2 0 ffff88013e7e9540 IN 0.0 0 0 [ksoftirqd / 0]
      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)
 
 
 Висновок
 
Аналіз і діагностика причин падіння ядра являє собою дуже специфічну і складну тему, яку неможливо вмістити в рамки однієї статті. Ми ще повернемося до неї в наступних публікаціях.
 
Для бажаючих дізнатися більше — кілька корисних посилань:
  
Читачів, які не можуть залишати коментарі тут, запрошуємо до нас в блог .
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.