GNU/Linux >> Linux Esercitazione >  >> Cent OS

Esempio di file di configurazione /etc/kdump.conf

Un'immagine della memoria di sistema acquisita dopo un arresto anomalo o un blocco del kernel è chiamata dump di arresto anomalo. L'analisi di un dump di arresto anomalo può fornire preziosi indizi per le analisi post mortem dei problemi del kernel. Tuttavia, ottenere un dump dopo un arresto anomalo del kernel è intrinsecamente inaffidabile perché il driver di archiviazione responsabile della registrazione dei dati sul dispositivo di dump potrebbe trovarsi in uno stato non definito.

Le impostazioni di configurazione di kdump vengono salvate nel file di configurazione /etc/kdump.conf. Di seguito è riportato un esempio di file /etc/kdump.conf da una macchina CentOS/RHEL 8.

# cat /etc/kdump.conf
# Questo file contiene una serie di comandi da eseguire (in ordine) nel kernel kdump
# dopo che si è verificato un crash del kernel nel kernel di crash (1° kernel).
#
# Le direttive in questo file sono applicabili solo a kdump initramfs e
# non hanno effetto una volta che il filesystem di root è montato e i normali script di inizializzazione sono
# elaborati.
#
# Attualmente, è possibile specificare solo una destinazione e un percorso di dumping. Se il dumping su
# la destinazione configurata non riesce, verrà eseguita l'azione di errore che può essere configurata tramite
# la direttiva "failure_action".
#
# Opzioni supportate:
#
# raw
# – Verrà aggiunto /proc/vmcore in .
# Usa nomi di dispositivi persistenti per i dispositivi di partizione,
# come /dev/vg/.
#
# nfs
# – Monta nfs su e copia /proc/vmcore su
# //%HOST-%DATE/, supporta DNS.
#
# ssh
# – Salverà /proc/vmcore in :/%HOST-%DATE/,
# supporta DNS.
# NOTA:assicurati che l'utente disponga delle autorizzazioni di scrittura sul server.
#
# sshkey
# – Userà sshkey per eseguire il dump ssh.
# Specificare il percorso della chiave ssh da utilizzare durante il dump
# tramite ssh. Il valore predefinito è /root/.ssh/kdump_id_rsa.
#
#
# – Verrà montato -t , e copia
# /proc/vmcore in //%DATE/.
# NOTA: può essere un nodo dispositivo, un'etichetta o un uuid.
# È si consiglia di utilizzare nomi di dispositivi persistenti
# come /dev/vg/.
# In caso contrario si consiglia di utilizzare label o uuid.
#
# percorso
# – “percorso” rappresenta il percorso del file system in cui verrà salvato vmcore
#. Se viene specificata una destinazione del dump in
# kdump.conf, allora "percorso" è relativo alla
# destinazione del dump specificata.
#
# L'interpretazione di "percorso" cambia a bit se l'utente non
# ha specificato esplicitamente alcuna destinazione del dump in kdump.conf. In questo
# caso, "percorso" rappresenta il percorso assoluto dalla radice. Il
# destinazione del dump e il percorso regolato vengono raggiunti automaticamente
# a seconda di cosa è montato nel sistema corrente.
#
# Ignorato per i dump dei dispositivi non elaborati. Se non è impostato, utilizzerà il valore predefinito
# “/var/crash”.
#
# core_collector
# – Ciò consente di specificare il comando per copia
# il vmcore. L'impostazione predefinita è makedumpfile, che su
# alcune architetture possono ridurre drasticamente le dimensioni di vmcore.
# Vedere /sbin/makedumpfile –help per un elenco di opzioni.
# Notare che -i e - g le opzioni non sono necessarie qui,
# poiché initrd verrà automaticamente popolato con un
# file di configurazione appropriato per il kernel in esecuzione.
# Il core_collector predefinito per il dump raw/ssh è:
# “makedumpfile -F -l –message-level 7 -d 31”.
# Il core_collector predefinito per altri target è:
# “makedumpfile -l –message-level 7 -d 31 ”.
#
# “makedumpfile -F” creerà un vmcore appiattito.
# Devi usare “makedumpfile -R” per riorganizzare i dati del dump in
# un normale dumpfile leggibile con strumenti di analisi. Ad esempio:
# “makedumpfile -R vmcore #
# Per i dettagli sul formato core_collector, puoi fare riferimento a
# kexec-kdump-howto.txt o kdump.conf manpage.
#
# kdump_post
# – Questa direttiva consente di eseguire un file binario eseguibile
# o uno script al termine del processo di dump di vmcore.
# Lo stato di uscita del processo di dump corrente viene inviato a
# il binario eseguibile o lo script come primo argomento.
# Tutti i file in /etc/kdump/post.d sono ordinati collettivamente
# ed eseguiti in ordine lessicale, prima del binario o dello script
# viene eseguito il parametro kdump_post specificato.
#
# kdump_pre
# – Funziona come la direttiva "kdump_post", ma invece di eseguire
# dopo il processo di dump, viene eseguito immediatamente prima di esso.
# Lo stato di uscita di questo binario viene interpretato come segue:
# 0 – continua con il processo di dump come al solito
# non 0 – esegui l'azione finale (reboot/poweroff/halt)
# Tutti i file in /etc/kdump/pre.d sono collettivamente ordinato e
# eseguito in ordine lessicale, dopo il binario o lo script specificato
# viene eseguito il parametro kdump_pre.
# Anche se il binario o lo script nella directory /etc/kdump/pre.d
# restituisce uno stato di uscita diverso da 0, l'elaborazione è continuata.
#
# extra_bins
# – Questa direttiva ti consente di specificare binari aggiuntivi o
# script di shell da includere in kdump initrd.
# Generalmente sono utili insieme a kdump_post
# o kdump_pre binario o script che dipende da questi extra_bins.
#
# extra_modules
# – Questa direttiva consente di specificare moduli kernel aggiuntivi
# che vuoi caricare in kdump initrd.
# È possibile elencare più moduli, separati da spazi, e tutti i
# moduli dipendenti verranno automaticamente inclusi.
#
# fallimento_azione
# – Azione da eseguire in caso di esito negativo del dumping.
# reboot:riavvia il sistema.
# halt:arresta il sistema.
# poweroff:spegni il sistema.
# shell:passa a una shell bash.
# L'uscita dalla shell riavvia il sistema per impostazione predefinita,
# o esegui "final_action".
# dump_to_rootfs:scarica vmcore in rootfs da initramfs e
# riavviare per impostazione predefinita o eseguire "final_action".
# Utile quando viene specificata una destinazione del dump non root.
# L'opzione predefinita è "reboot".
#
# predefinito
# – Come la precedente direttiva "failure_action", ma questa direttiva
# è obsoleta e verrà rimossa in futuro.
#
# final_action
# – Azione da eseguire in caso di esito positivo del dumping. Eseguito anche
# al termine dell'azione di errore "shell" o "dump_to_rootfs".
# Ogni azione è uguale alla direttiva "failure_action" sopra.
# L'impostazione predefinita è "reboot".
#
# force_rebuild <0 | 1>
# – Per impostazione predefinita, kdump initrd verrà ricostruito solo quando necessario.
# Specifica 1 per forzare la ricostruzione di kdump initrd ogni volta che il servizio kdump
# viene avviato.
#
# force_no_rebuild <0 | 1>
# – Per impostazione predefinita, kdump initrd verrà ricostruito quando necessario.
# Specifica 1 per ignorare la ricostruzione di kdump initrd.
#
# Le opzioni force_no_rebuild e force_rebuild sono mutualmente
# esclusivi e non devono essere impostati su 1 contemporaneamente.
#
# override_resettable <0 | 1>
# – Di solito un dispositivo a blocchi non ripristinabile non può essere una destinazione del dump.
# Specificando 1 quando si desidera eseguire il dump anche se il blocco
# destinazione non è ripristinabile
# Per impostazione predefinita, è 0, che non tenterà di eseguire il dumping destinato a fallire.
#
# dracut_args
# – Passa opzioni di dracut extra durante la ricostruzione di kdump initrd.
#
# fence_kdump_args
# – Argomenti della riga di comando per fence_kdump_send (può contenere
# tutti gli argomenti validi tranne gli host a cui inviare la notifica).
#
# fence_kdump_nodes
# – Elenco di nodi cluster eccetto localhost, separati da spazi,
# a cui inviare le notifiche fence_kdump.
# ( questa opzione è obbligatoria per abilitare fence_kdump).
#

#raw /dev/vg/lv_kdump
#ext4 /dev/vg/lv_kdump
#ext4 LABEL=/boot
#ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937
#nfs my.server.com:/export/tmp
#nfs [2001:db8::1:2:3:4]:/export/tmp
#ssh [email protected]. com
#ssh user@2001:db8::1:2:3:4
#sshkey /root/.ssh/kdump_id_rsa
percorso /var/crash
core_collector makedumpfile - l –message-level 7 -d 31
#core_collector scp
#kdump_post /var/crash/scripts/kdump-post.sh
#kdump_pre /var/crash/scripts/kdump-pre .sh
#extra_bins /usr/bin/lftp
#extra_modules gfs2
#failure_action shell
#force_rebuild 1
#force_no_rebuild 1
#dracut_args –omit -drivers “cfg80211 snd” –add-drivers “ext2 ext3”
#fence_kdump_args -p 7410 -f auto -c 0 -i 10
#fence_kdump_nodes node1 node2


Cent OS
  1. In che modo Linux gestisce più separatori di percorsi consecutivi (/home////nomeutente///file)?

  2. Come viene aggiornato /etc/motd?

  3. Spiegazione del file di configurazione DNS /etc/named.conf

  4. Comprensione del file di configurazione dm-multipath /etc/multipath.conf

  5. Esempio di file /etc/multipath.conf

Comprensione del file di configurazione di kdump /etc/kdump.conf

Comprensione del file /etc/security/limits.conf

Come monitorare i file /etc/shadow e /etc/passwd per le modifiche con Auditd?

Spiegazione del file di configurazione DHCP /etc/dhcp/dhcpd.conf

Esempio di file /etc/mke2fs.conf

Differenza tra /etc/hosts e /etc/resolv.conf