Come configurare la funzionalità di supporto Early-kdump in CentOS/RHEL 8

Cos'è il supporto iniziale di kdump?

Nelle versioni precedenti di CentOS/RHEL (5/6/7), il servizio kdump si avviava molto tardi nella sequenza di avvio. Quindi le informazioni sugli arresti anomali iniziali vengono perse durante l'avvio. A partire da CentOS/RHEL 8, è stato introdotto un nuovo meccanismo kdump chiamato "early kdump support" per affrontare questo problema. I primi Kdump archiviano vmlinuz e initramfs del kernel di crash all'interno degli initramfs del kernel di avvio e li caricano direttamente nella memoria riservata (crashkernel) durante la fase di avvio iniziale.

Il pacchetto "kexec-tools" ora ha 2 moduli extra per caricare il kernel di arresto anomalo e initramfs il prima possibile durante la sequenza di avvio per acquisire il dump di arresto anomalo del kernel del kernel di avvio.

/usr/lib/dracut/modules.d/99earlykdump/early-kdump.sh
/usr/lib/dracut/modules.d/99earlykdump/module-setup.sh

# dracut --list-modules | grep earlykdump
earlykdump

Per impostazione predefinita, il supporto iniziale di kdump è disabilitato e dobbiamo abilitarlo manualmente. Supporta anche tutti i target di dump e i parametri di configurazione supportati dalle precedenti configurazioni di kdump in CentOS/RHEL 5,6,7.

Configura il servizio kdump

1. Fai riferimento al post di configurazione di kdump di seguito per configurare kdump e assicurarti che il servizio kdump sia in esecuzione.

CentOS / RHEL 7:come configurare kdump

# systemctl enable --now kdump.service

# systemctl status kdump.service
● kdump.service - Crash recovery kernel arming
Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: enabled)
Active: active (exited) since Mon 2019-08-19 23:42:11 IST; 16h ago
Main PID: 1255 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 26213)
Memory: 0B
CGroup: /system.slice/kdump.service

Aug 19 23:42:09  systemd[1]: Starting Crash recovery kernel arming...
Aug 19 23:42:11  kdumpctl[1255]: Kdump already running: [WARNING]
Aug 19 23:42:11  systemd[1]: Started Crash recovery kernel arming.

2. Elenca i moduli di dumping anticipato disponibili nel sistema

# dracut --list-modules | grep earlykdump
earlykdump 

3. Aggiungi il parametro rd.earlykdump a kernelopts riga in /boot/grub2/grubenv file:

# cat /boot/grub2/grubenv
# GRUB Environment Block
saved_entry=4eb68bf18e86437d9c957ff4863a3288-4.18.0-80.el8.x86_64
kernelopts=root=/dev/mapper/ol-root ro crashkernel=auto resume=/dev/mapper/ol-swap rd.lvm.lv=ol/root rd.lvm.lv=ol/swap rd.earlykdump
boot_success=0
###################################################################################################
###################################################################################################
###################################################################################################

Ricrea iniramfs

1. Ora il passaggio successivo consiste nel ricreare initramfs per aggiungere i primi moduli di kdump:

# lsinitrd | grep -i early

# dracut -f --add earlykdump

Ad esempio:

# lsinitrd |grep -i early
Arguments: -f --add 'earlykdump'
earlykdump
-rwxr-xr-x 1 root root 1940 Jun 17 10:29 usr/lib/dracut/hooks/cmdline/00-early-kdump.sh 

2. Riavvia la casella per caricare le modifiche

# reboot

3. Una volta che il server è tornato online, controlla lo stato di early-kdump:

# journalctl -x |grep -i early-kdump
Aug 20 16:08:09 [HOSTNAME] dracut-cmdline[196]: early-kdump is enabled.
Aug 20 16:08:10 [HOSTNAME] dracut-cmdline[196]: kexec: loaded early-kdump kernel

Test di kdump anticipato

Ora testiamo il primo kdump usando file di unità di sistema personalizzati e creiamo il panico usando SysRq in crash.

1. Crea un nome file di unità /etc/systemd/system/test_early_kdump.service .

# touch /etc/systemd/system/test_early_kdump.service

2. Fornire le autorizzazioni appropriate:

# chmod 664 /etc/systemd/system/test_early_kdump.service

Il file dell'unità dovrebbe apparire come di seguito:

# cat /etc/systemd/system/test_early_kdump.service
[Unit]
Description=test_early_kdump Service
Before=kdump.service

[Service]
ExecStart=/usr/local/test_early_kdump.sh
Type=simple

[Install]
WantedBy=default.target

3. Quindi crea un altro script /usr/local/test_early_kdump.sh file per passare il comando di arresto anomalo di sysrq:

# cat /usr/local/test_early_kdump.sh
#!/bin/bash
/usr/bin/echo c > /proc/sysrq-trigger

4. Fornire l'autorizzazione eseguibile per lo script:

# chmod +x /usr/local/test_early_kdump.sh

5. Ricarica il demone systemd:

# systemctl daemon-reload

IMPORTANTE :Non avviare il servizio test_early_kdump.service (test crash), altrimenti il ​​sistema andrà in crash immediatamente.

6. Abilita questo servizio test_early_kdump a livello di avvio:

# systemctl enable test_early_kdump.service

7. Riavvia il sistema:

# reboot

Nota :Durante l'avvio del sistema secondo lo script di test personalizzato, attiverà un arresto anomalo e continuerà a riavviarsi.

8. Disabilitare l'unità personalizzata e i file di script e rimuoverli dopo il test. Avvia il sistema in modalità di ripristino utilizzando "systemd.unit=rescue.target ' e disabilita il servizio 'test_early_kdump' all'avvio.

# systemctl disable test_early_kdump.service

Il comando sopra disabilita il file di unità personalizzato. La prossima volta il sistema si avvierà normalmente.

Come avviare la modalità di soccorso o la modalità di emergenza tramite Systemd in CentOS/RHEL 7 e 8

9. Rimuovere i file dell'unità personalizzata e il file di script di arresto anomalo al termine dell'arresto anomalo del TEST:

# rm /etc/systemd/system/test_edump.service
rm: remove regular file '/etc/systemd/system/test_edump.service'? y 

# rm /usr/local/test_early_kdump.sh

10. Controlla /var/crash/ cartella come da kdump.conf (percorso /var/crash) menzionato per vmcore:

# ls -l /var/crash/127.0.0.1-2019-08-20-17:09:23
total 56648
-rw-------. 1 root root 57959829 Aug 20 17:09 vmcore
-rw-r--r--. 1 root root 41452 Aug 20 17:09 vmcore-dmesg.txt