Warning message

This translation is outdated. For the most up-to-date information, please refer to the English version.

Come si configura il kexec/kdump su Red Hat Enterprise Linux?

Solution Verified - Updated -

Environment

  • Red Hat Enterprise Linux 5
  • Red Hat Enterprise Linux 6

Issue

  • Cosa sono i kdump e kexe e come si configurano?

Resolution

Nota: 'xendump' per i Xen guests. Consultare Come configurare Xendump su Red Hat Enterprise Linux 5?
per KVM e RHEV, consultare Come ottenere un vmcore dump da un KVM guest?

Background / Panoramica

kexec è un meccanismo di fastboot che constente il boot di un kernel Linux dal contesto di un kernel già in esecuzione senza passare dal BIOS. Siccome il BIOS esegue dei controlli durante lo startup, puo impiegare una quantita eccessiva di tempo (specialmente su server grandi con numerose periferiche), kexec puo risparmiare parecchio tempo per gli sviluppatori che hano bisogno di effettuare il reboot della macchina spesso a per dei test.Usare kexec per effettuare il reboot su kernel normali è molto semplice, ma non non è lo scopo dimostrativo di questo articolo. Visitare la pagina del man kexec(1) per ulteriori informazioni.

kdump è un meccanismo affidabile di crash-dumping che utilizza kexec. I crash dumps sono ottenuti da un contesto di kernel appena avviati e non da un contesto di kernel che hanno subito crash. Il kdump usa kexec per avviare il sistema su un secondo kernel ogni vota che il sistema subisce un crash. Questo secondo kernel, chiamato spesso 'capture kenel', si avvia con poca memoria e ne ottiene l'immagine.

Il primo kernel riserverà una sezione di memoria che il secondo kernel userà per il boot. Siate consapevoli che la memoria riservata per il kernel kdump al boot non puo' essere usata dal kernel standard, il che effettivamente cambia i requisiti minimi della memoria per Red Hat Enterprise Linux. Per calcolare i requisiti minimi effettivi per un sistema, consultare Capacita' e limiti tecnologici di Red Hat Enterprise Linux 6 per i requisiti minimi elencati ed aggiungere la quantita di memoria usata da kdump per determinare i requisiti effettivi.

Usare kdump constente di eseguire il boot per il capture kernel bypassando il BIOS pertanto i contenuti della memoria del primo kernel sono preservati, il che si tratta essenzialmente di crash dump.

Per iniziare la procedura di dump dei kernel core con kdump, bisogna seguire le seguenti istruzioni.

Prerequisiti

  • Per eseguire un core dump su una determinata network, e' necessario l'accesso su un server attraverso NFS o ssh.

  • Sia se eseguiate il dump localmente o su una specifica network, e' necessario un dispositivo o una cartella con abbastanza spazio libero per tenere il core. Consultare la sezione "Dimensionare i Dump Targer locali" più in basso per avere maggiori informazioni riguardo la quantità di spazio necessaria.

  • Per configuare il kdump su un sistema con un kernel Xen, e' necessario avere un kernel normale della stessa versione del kernel Xen installato nel sistema.
    (Notare che se il sistema e' a 32/bit con piu di 4Gb di RAM, dovrebbe essereci installato kernel-pae insieme a kernel-xen invece di kernel.)

Installare kdump

Verificare che il pacchetto kexec-tools sia installato:

# rpm -q kexec-tools

Se non lo e' procedere all'installazione via yum:

# yum install kexec-tools

Su IBM Power (ppc64) ed IBM System z (s390x), il capture kernel e' fornito nel pacchetto separato kernel-kdump il quale deve essere installato per far funzionare il kdump:

# yum install kernel-kdump

Questo pacchetto non e' necessario ( e di fatti non esiste) su altre architetture.

Aggiungere parametri di Boot

L'opzione crashkernel deve essere aggiunta nei parametri della linea di comando kernel command line per poter riservare memoria al kernel kdump kdump.Per le architetture i386 e x87_64 su RHEL 5, modificare /etc/grub.conf, ed apporre crashkernel=128M@16M alla fine della linea kernel. Per sistemi RHEL 6 i387 ed x86_64 usare crashkernel=128M.

Nota: potrebbe essere possibile usare meno di 128M,ma effettuare i test con solo 64M è risultato poco affidabile.

Nota: per piu informazioni riguardo al parametro crashkernel su RHEL6 consultare l'articolo Come dovrebbero esssere configurati i parametri di crashkernel per l'uso di kdump per RHEL6?

A seguire è un esempio di /etc/grub.conf con le opzioni di kdump aggiunte per RHEL 5:

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You do not have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /, eg.
#          root (hd0,0)
#          kernel /boot/vmlinuz-version ro root=/dev/hda1
#          initrd /boot/initrd-version.img
#boot=/dev/hda
default=0
timeout=5
splashimage=(hd0,0)/boot/grub/splash.xpm.gz
hiddenmenu
title Red Hat Enterprise Linux Client (2.6.17-1.2519.4.21.el5)
        root (hd0,0)
        kernel /boot/vmlinuz-2.6.17-1.2519.4.21.el5 ro root=LABEL=/ rhgb quiet crashkernel=128M@16M
        initrd /boot/initrd-2.6.17-1.2519.4.21.el5.img

O per RHEL 6:

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/mapper/vg_jrummy-lv_root
#          initrd /initrd-[generic-]version.img
# boot=/dev/vda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Red Hat Enterprise Linux Server (2.6.32-71.7.1.el6.x86\_64)
       root (hd0,0)
       kernel /vmlinuz-2.6.32-71.7.1.el6.x86_64 ro root=/dev/mapper/vg_example-lv_root rd_LVM_LV=vg_example/lv_root rd_LVM_LV=vg_example/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us crashkernel=128M rhgb quiet
       initrd /initramfs-2.6.32-71.7.1.el6.x86_64.img

Nota: Se state usando un kernel Xen su RHEL 5 avra bisogno di aggiungere il parametro crashkernel alla fine della linea di comando del kernel e non del modulo, anche se quest'ultima si riferisce al kernel Linux vmlinuz.

Per quando si usa un kernel Xen per RHEL 5:

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You do not have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /, eg.
#          root (hd0,0)
#          kernel /boot/vmlinuz-version ro root=/dev/hda1
#          initrd /boot/initrd-version.img
# boot=/dev/hda
default=0
timeout=5
splashimage=(hd0,0)/boot/grub/splash.xpm.gz
hiddenmenu
title Red Hat Enterprise Linux Server (2.6.18-194.17.1.el5xen)
       root (hd0,0)
       kernel /xen.gz-2.6.18-194.17.1.el5 crashkernel=128M@16M
       module /vmlinuz-2.6.18-194.17.1.el5xen ro root=/dev/myvg/rootvol
       module /initrd-2.6.18-194.17.1.el5xen.img

Note: Dopo aver aggiunto un parametro crashkernel il sistema deve essere riavviato per permettere alla memoria del crashkernel di essere riservata per un futuro uso di kdump.Questo riavvio può essere effettuato immediatamente o dopo aver eseguito alcuni step per configurare kdump esaminati successivamente in questo articolo .

Specificare l'ubicazione del Kdump

L'ubicazione del vmcore kdump puo essere specificata in /etc/kdump.conf. E' possibile eseguire il dump direttamente sia su un dispositivo che su un file o da qualche parte nel network via NFS o SSH. Se l'ubicazione non è specificate nella configurazione, verranno usati i valori di default pertanto i core verranno salvati in /var/crash nel file sistem di root. Per informazioni sulle ubicazioni supportate del dump consultare Quali ubicazioni sono supportate per l'uso di kdump?

Eseguire il Dump direttamente su un dispositivo

Puo' configurare kdump in modo da scrivere l'immagine direttamente su un device usando la direttiva RAW in /etc/kdump.conf. La sintassi da usare e':

raw *<devicename>*

Per esempio:

raw /dev/sda1

Questo comando sovrascrivera ogni dato presente nel dispositivo.

Eseguire il dump su un file su disco

kdump puo essere configurata in modo da montare una partizione ed eseguire il dump su un file su dusco. Per fare cio bisogna specificare il ftipo di filesystem seguito dal dispositivo /etc/kdump.conf. Questo dispositivo puo essere specificato come 'device node','filesystem label' o 'filesystem UUID' esattamente come /etc/fstab. Per esempio:

ext3 /dev/sda1

montera /dev/sda1 come dispositivo ex3 ed eseguira il dump del core sulla directory /var/crash/ (e crearla se necessario), mentre:

ext3 LABEL=/boot

montera' il dispositivo che e' ext3 con label /boot e lo usera per il dump del core.

Potrebbe esserci il bisogno di impostare il label manualmente per dispositivi di storage che sono stati configurati dopo che sia stato installato Red Hat Enterprise Lunux.Per esempio il seguente comando impostera il label 'crash' sul dispositivo di storage '/dev/sdd1':

# e2label /dev/sdd1 crash

Per visualizzare il label di un dispositivo id storage, eseguire 'e2label' con il dispositivo come unico argument:

# e2label /dev/sdd1

Un modo facile per trovare come specificare il dispositivo e' guardare a cosa e' in uso su /etc/fstab (il filesystem sul quale state cercando di fare il dump non necessita di essere montato perennemente via fstab). La directory di defaul nella quale verra effetuato il dump dei core e' <filesystem>/var/crash/*<date>*/ dove date e' la data corrente al momento del crash dump. Si puo' modificare cio usando la direttiva path in /etc/kdump.conf.Ad esempio:

ext3 UUID=f15759be-89d4-46c4-9e1d-1b67e5b5da82 
path /usr/local/cores

eseguera' il dump del vmcore su <filesystem>/usr/local/cores/ al posto dell'ubicazione di default <filesystem>/var/crash/.

Dump su un dispositivo Network usando NFS

Per configurare il kdup per effettuare il dump su una mount NFS, modificare /etc/kdump.conf ed aggiungere una linea con il seguente formato:

net *<nfs server>:</nfs/mount>*

Per esempio:

net nfs.example.com:/export/vmcores

Questo fara il dump del vmcore su /var/crash/*<hostname>*-*<date>*/ sul server nfs.example.com. Il sistema del client deve avere accesso per scivere questo mount point.

NOTA: Quando si esegue il dump su una risorsa di rete connessa tramite una interfaccia in bonding, potrebbe essere necessario definire le opzioni del modulo di bonding nel file kdump.con. Consultare kdump non accetta opzioni del modulo da files ifcfg-* per piu informazioni.

Eseguire il Dump su un dipositivo di Network usando SSH

SSH ha il vantaggio di criptare le comunicazioni del network durante il dump. Per questa ragione, questa e' la soluzione migliore per quando si richiede un dump di un vmcore attravero un network accessibile pubblicamente come Interet o una WAN aziendale:

net *<user>@<ssh server>*

Per esempio:

net kdump@crash.example.com

In questo caso, kdump usera' scp per connetersi al server crash.example.com usando l'user del kdump. Esso copiera il vmcore sulla directory /var/crash/*<hostname>*-*<date>*``*/*. L'user del kdump avrà bisogno dei necessari permessi di scrittura sul server remoto. Inoltre, si noti che quando si configura kdump per usare SSH, provera ad usare il binary ktemp nel target system per assicurarsi i permessi di scrittura nel target path. Se il vostro kdump target server sta eseguendo un sistema operativo senza la mktemp binary, sarà necessario usare un metodo diverso per salvare un vmcore su quel target.

Per far si che questo cambiamento venga effettuato, eseguire service kdump propagate, il quale dovrebbe dare un output simile al seguente:

# service kdump propagate
Generating new ssh keys... done,
kdump@crash.example.com's password:
/root/.ssh/kdump_id_rsa.pub has been added to
~kdump/.ssh/authorized_keys2 on crash.example.com

Assicurarsi che lo spazio libero della partizione o della location nel network specificata per allocare il vmcore sia grande almeno quanto l'intera memoria fisica nel sistema.

Dump su un dispositivo SAN

Ottenere il wwid per i percorsi del san:

# /sbin/scsi_id -g -u -s /block/sd<x>

Mettere nella blacklist questo lun dal multipath modificando/etc/multipath.conf

blacklist {
  wwid "3600601f0d057000019fc7845f46fe011"  
}

Ricaricare la configurazione del multipath

# /etc/init.d/multipathd reload  

Ora prendere una partizione creata sul nostro lun, assicurarsi di avere quella giusta

# fdisk -l  
# /sbin/scsi_id -g -u -s /block/sd<x>
# fdisk /dev/sd<x>

Creare una partizione linux sul disco

# partprobe /dev/sd<x>

Verificare che la partizione sia presente

# fdisk -l 

Immettere un ext3 fs (probabilmente potrebbe ancare anche ext4)

# mkfs.ext3 /dev/sd<x>1

Ora immettere una udev rule

# cat 99-crashlun.rules
KERNEL=="sd*", BUS=="scsi", ENV{ID_SERIAL}=="3600601f0d057000019fc7845f46fe011", SYMLINK+="crashsan%n"

Adesso bisogna impostare udev in modo da non influenzare qualsiasi altra cosa

# echo change > /sys/block/sd<x>/sd<x>1/uevent

Verificare che la regola di udev ha funzionato, cercando /dev/crashsan1

# ls /dev/

Ora aggiornare /etc/fstab aggiungendo la seguente riga alla fine del file

/dev/crashsan1         /var/crash       ext3    defaults    0 0

Verificare che sia tutto in regola

# mount -a 
# mount

Adesso abbiamo bisogno di modificare /etc/kdump.conf di conseguenza

ext3 /dev/crashsan1

Eseguire il restart kdump

# service kdump restart

Assicurarsi che sysrq sia abilitato e testare il crash, notare che questo provochera il crash del box, si faccia pertanto attenzione al momento in cui lo si effetua in caso questo sia un sistema di produzione.

# echo 'c' > /proc/sysrq-trigger

Una volta che il sistema finisce di riavviarsi controllare se ha funzionato

# tree /var/crash/
/var/crash/
|-- 2012-08-03-13:57
|   `-- vmcore
`-- lost+found

Nota: questo e' stato verificato su RHEL5, molto probabilmente funzionera anche su RHEL6.

# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 5.8 (Tikanga)

# uname -a
Linux somecoolserver.redhat.com 2.6.18-308.el5 #1 SMP Fri Jan 27 17:17:51 EST 2012 x86_64 x86_64 x86_64 GNU/Linux

Dimensionare i Local Dump Targets

La dimensione del file di core, e di conseguenza l'ammontare di spazio sul disco necessario per memorizzarla, dipendera da quanta RAM sia in uso e dal tipo di dati memorizzati su di essa. L'unico modo per garantire un dump riuscito e' di avere tanto spazio libero sul disco quanto la RAM fisica. Tuttavia usando l'opzione core_collector (consultare il paragrafo "Specificare la Selezione e Compressione del Page" riportato piu in basso) si puo comprimere il core dump e rimuovere da esso specifici tipi di page. Questo dovrebbe far risparmiare parecchio spazio, ma ancora una volta dipene da come il sistema viene usato. Il rapporto id compressione uttenuto usando l'opzione "-c" dipende interamente dai contenuti della RAM; alcuni vengono compressi meglio di altri.

La cosa migliore da fare per determinare lo spazio richiesto e' di testare il dump durante l'uso tipco del sistema usando il SysRq "c" per provocare il crash del sistema e generare un core campione. Effettuare il dump su un dump server dedicato via NFS o SSH usando l'opzione "net" su kdump.conf (consultare il paragrafo "Dump su un dispositivo Network" esaminato precedentemente) puo aiutare all'eliminazione della necessita di storage locale riservato e ridurre i requisiti complessivi di dump storage. Dump server su network centralizzati riducono le necessita complessive di storage attraverso economia di scala, specificamente sull'improbabilita' che tutti i sistemi che confividino il dump server centrale avranno bisogno di usare lo storage dumpings durante periodi sovrapposti.

Specificare la Selezione e Compressione del Page

Su sistemi con grande memoria, e' cosigliabile sia di scartare page che non sono necessari che comprimere i page rimanenti. Cio' e' fattibile in kdump.conf col comando core_collector. A questo punto in essi l'unico core collettor pienamente supportato e' makedumpfile. l'opzione puo essere visualizzata con makedumpfile --help. L'opzione -d specifica quale tipo di page dovrebbe essere lasciata fuori. L'opzione e' una bit mask, avendo ogni tipo di page specificata cosi:

zero pages   = 1
cache pages   = 2
cache private = 4
user  pages   = 8
free  pages   = 16

General
In general, these pages don't contain relevant information. To set all these flags and leave out these pages, use a value of -d 31. The -c tells makedumpfile to compress the remaining data pages.

# throw out zero pages (containing no data)
# core_collector makedumpfile -d 1 
# throw out all trival pages         
# core_collector makedumpfile -d 31         
# compress all pages, but leave them all
# core_collector makedumpfile -c            
# throw out trival pages and compress (recommended)
core_collector makedumpfile -d 31 -c       

Nota: quando si effettua un cambiamento su kdump.conf, e' rischiesto di effettuare un service kdump restart. Se avrete intensione di riavviare il sistema successivamente, questo step puo essere saltato.

Sistemi in Cluster

Si puo' eseguire il fence/reboot dei Cluster node possono prima che kdump abbia tempo per essere completato. Se il sistema monta Red Hat High Availability Add-on, RHEL Advanced Platform Cluster o Red Hat Cluster Suite,sara necessario incrementare il parametro post_fail_delay in /etc/cluster/cluster.conf. Bisognera' dare al sistema abbastanza tempo per completare il kdump ptima di eseguire il fence.Il tempo richiesto dipendera' dall'ammontare di memoria nel sistema e dalla velocita' della connessione con il dump target.Seguire i testing step elencati piu in basso e' il metodo miglire per determinare il tempo necessario.

Testing

Dopo aver effettuato i cambiamenti descritti in precedenza,riavviare il sistema.I 128M di memoria (iniziando da 16M nella memoria) sono lasciati stare dal sistema normale e vengono riservati per il capture kernel.Notare che l'output di free -m mostra 128M in meno di memoria che senza questo parametro, il che e' normale.

Ora che la regione di memoria riservata e' stata impostata, avviare l'init script del kdump e avviare il servizio:

#  chkconfig kdump on
#  service kdump start

Questo creera' una /boot/initrd-kdump.img, lasciando il sistema pronto a catturare un vmcore durante un crash.Per testare questo, bisogna forzare un crash del sistema innescando un crash con sysrq:

Attenzione: Questo mandera' il kernel in panic, disattivando tutti i servizi nella macchina.

# echo c > /proc/sysrq-trigger

(Per maggiori informazioni su sysrq, consultare l'articoloCos'e' la SysRq facility e come si usa?.)

Questo manda il kernel in panic,seguito dal restart del server sul kdump kernel.Quando il processo di boot arriva al punto in cui si avvia il kdump service, il vmcore dovrebbe venire copiato sulla locazione specifica nel file /etc/kdump.conf.

Controllare quando il kdump viene attivato

Ci sono diversi parametri che There are several parameters that control under which circumstances kdump is activated. kdump can be activated when

  • e' stato individuato un system hand attraverso il mecanismo di Non-Maskable Interrupt (NMI) Watchdog.
    Questo meccanismo e' abilitato attraverso il parametro del kernel nmi_watchdog=1 . Consultare Cos'e' NMI e per cosa lo si puo` usare? per ulteriori dettagli.
  • e' stato premuto un tasto NMI hardware.
    Questo meccanismo viene abilitato impostando il sysctl kernel.unknown_nmi_panic=1 .
  • Si e' verificato un "unrecovered" NMI.
    questo meccanosmo e' abilitato impostando il sysctl kernel.panic_on_unrecovered_nmi=1 .
    I seguenti messaggi di avverteenza dal kernel sono associato con "unrecovered" NMIs:
Uhhuh. NMI received for unknown reason *hexnumber* on CPU *CPUnumber*.
Do you have a strange power saving mode enabled?
Dazed and confused, but trying to continue
  • l' out-of-memory killer (oom-killer) dovrebbe essere altresi innescato triggered.
    Questo puo essere configurato impostando il sysctl vm.panic_on_oom=1 .

Commenti

I frame-buffers ed X della Console non sono propiamente supportati.Su un sistema tipicamente eseguito con qualcosa del tipo"vga=791" nella kernel config line o con X in esecuzione, il console video sara' ingarbugliato quando un kernel viene avviato via kexec. Notare che il kdump kernel dovrebbe essere ancora in grado di ottenere un dump, e quando il sistema si riavvia, il video dovrebbe essere ripristinato alla normalita'.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.