Documentation<Précédent | Table des matières | Suivant>
6.6. Test du mécanisme de vidage sur incident
Le test du mécanisme de vidage sur incident entraînera un redémarrage du système. Dans certaines situations, cela peut entraîner une perte de données si le système est soumis à une charge importante. Si vous souhaitez tester le mécanisme, assurez-vous que le système est au repos ou sous une charge très faible.
Vérifiez que le RQSys mécanisme est activé en regardant la valeur du / proc / sys / noyau / sysrq paramètre du noyau :
cat / proc / sys / kernel / sysrq
Si une valeur de 0 est renvoyé le vidage, puis la fonction de redémarrage est désactivée. Une valeur supérieure à 1 indique qu'un sous-ensemble de fonctionnalités sysrq est activé. Voir /etc/sysctl.d/10-magic-sysrq.conf pour une description détaillée des options et de la valeur par défaut. Activez le vidage puis redémarrez le test avec la commande suivante :
sudo sysctl -w noyau.sysrq=1
Une fois cela fait, vous devez devenir root, car il suffit d'utiliser sudo ne suffira pas. Comme le racine utilisateur, vous devrez exécuter la commande echo c > /proc/sysrq-trigger. Si vous utilisez une connexion réseau, vous perdrez le contact avec le système. C'est pourquoi il est préférable de faire le test en étant connecté à la console système.
Cela a l'avantage de rendre visible le processus de vidage du noyau. Une sortie de test typique devrait ressembler à ce qui suit :
Sudo -s
[sudo] mot de passe pour ubuntu :
# echo c > /proc/sysrq-trigger
[ | 31.659002] | SysRq : Déclenche un crash |
[ | 31.659749] | BOGUE : impossible de gérer le déréférencement du pointeur NULL du noyau à |
[ | 31.662668] | IP: [<ffffffff8139f166>] sysrq_handle_crash+0x16/0x20 |
[ | 31.662668] | PGD 3bfb9067 PUD 368a7067 PMD 0 |
[ | 31.662668] | Oups : 0002 [#1] SMP |
[ | 31.662668] | CPU 1 |
[ | 31.659002] | SysRq : Déclenche un crash |
[ | 31.659749] | BOGUE : impossible de gérer le déréférencement du pointeur NULL du noyau à |
[ | 31.662668] | IP: [<ffffffff8139f166>] sysrq_handle_crash+0x16/0x20 |
[ | 31.662668] | PGD 3bfb9067 PUD 368a7067 PMD 0 |
[ | 31.662668] | Oups : 0002 [#1] SMP |
[ | 31.662668] | CPU 1 |
(Null)
....
Le reste de la sortie est tronqué, mais vous devriez voir le système redémarrer et quelque part dans le journal, vous verrez la ligne suivante :
Commencer : enregistrer vmcore à partir d'un plantage du noyau...
Une fois terminé, le système redémarrera dans son mode de fonctionnement normal. Vous trouverez alors le fichier Kernel Crash Dump et les sous-répertoires associés dans le /var/accident répertoire :
ls /var/crash
201809240744 kexec_cmd linux-image-4.15.0-34-generic-201809240744.crash
Si le vidage ne fonctionne pas en raison d'une erreur OOM (Out Of Memory), essayez d'augmenter la quantité de mémoire réservée en éditant /etc/default/grub.d/kdump-tools.cfg. Par exemple, pour réserver 512 mégaoctets :
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=384M-:512M"
courir sudo mise à jour-grub puis redémarrez ensuite, puis testez à nouveau.