Capturer un core dump Linux et valider la chaîne de diagnostic

Lorsqu’un processus applicatif s’arrête brutalement, redémarrer le service rétablit son fonctionnement, mais n’explique pas la cause du plantage. Si les journaux ne contiennent qu’un numéro de signal, il faut aussi disposer de la pile d’appels au moment du plantage et du build correspondant. Ce guide met en place une chaîne de collecte contrôlée des core dumps sur Ubuntu Server 24.04. Elle sera d’abord validée avec un processus isolé, avant de décider de l’activer pour un service en production.

Les serveurs dédiés AMDSSH peuvent être équipés de 128Go ou 256Go de mémoire ECC. Cela ne signifie pas qu’il faut enregistrer sans restriction des dumps à hauteur de toute la mémoire du serveur. Un fichier core peut contenir des mots de passe, le corps de requêtes et des données métier : le périmètre de collecte, les limites de stockage et les droits d’accès doivent être configurés ensemble.

1. Identifier le type de plantage et le collecteur en place

Après le paiement, consultez les identifiants de connexion dans la console, puis connectez-vous en SSH. Les opérations suivantes nécessitent des droits d’administration. Avant le test, vérifiez le système, l’espace disque et le mécanisme de prise en charge des core dumps :

cat /etc/os-release
df -h /var/lib
sysctl kernel.core_pattern
sudo journalctl -b -p warning --no-pager

Lorsque kernel.core_pattern commence par une barre verticale, le noyau transmet le dump à un programme en espace utilisateur au lieu de l’écrire directement dans le répertoire courant. Un autre collecteur de plantages peut déjà être installé. Consignez la valeur d’origine et les paquets concernés : ne superposez pas deux mécanismes en supposant qu’ils fonctionneront tous les deux.

Commencez par distinguer une sortie volontaire, un arrêt provoqué par un signal et une terminaison due au manque de mémoire. SIGSEGV et SIGABRT déclenchent généralement un core dump, contrairement à SIGKILL. Un état de service indiquant une sortie anormale ne prouve pas qu’un fichier récupérable a été créé.

Un core dump contient des éléments de preuve issus de la mémoire d’un processus, pas de simples journaux d’exécution. Ne le placez jamais dans un répertoire public et ne le joignez pas à un ticket ou à un dépôt de code sans l’avoir examiné.

Installez les outils utilisés dans ce guide. Si le gestionnaire de paquets propose de remplacer un collecteur existant, vérifiez d’abord les conséquences, puis choisissez explicitement un seul mécanisme :

sudo apt-get update
sudo apt-get install systemd-coredump gdb gcc
sysctl kernel.core_pattern
systemctl status systemd-coredump.socket --no-pager

Après l’installation, le mécanisme doit pointer vers le gestionnaire de dumps de systemd. Le socket assure la réception et le service de traitement démarre à la demande. L’absence de processus de collecte permanent ne signifie donc pas que la fonction est inactive.

2. Fixer les limites de stockage de la chaîne de collecte

Créez /etc/systemd/coredump.conf.d/60-controlled-capture.conf avec la configuration suivante :

[Coredump]
Storage=external
Compress=yes
ProcessSizeMax=256M
ExternalSizeMax=256M
MaxUse=512M
KeepFree=2G

Ces quotas servent à valider la collecte sur un petit processus de test. Ils ne constituent pas des valeurs recommandées pour une application consommant beaucoup de mémoire. ProcessSizeMax limite la taille des dumps soumis au traitement, tandis que ExternalSizeMax limite celle des dumps enregistrés dans des fichiers externes. Si ces limites sont dépassées, seules les métadonnées de l’événement peuvent être conservées, sans fichier mémoire complet.

MaxUse et KeepFree contrôlent l’espace occupé par le répertoire des dumps externes. Ils ne garantissent pas une réserve d’espace disque et ne limitent pas la taille de la base de journaux. Des plantages simultanés peuvent toujours saturer le stockage : surveillez aussi l’espace libre du système de fichiers concerné.

Les prochains processus de traitement liront cette configuration. Pour vérifier le résultat de la fusion des fichiers de configuration, utilisez :

systemd-analyze cat-config systemd/coredump.conf

Avant l’activation en production, mesurez la consommation mémoire d’un processus représentatif et la taille réelle de son dump, puis ajustez les plafonds. La réussite du test ne garantit pas qu’un dump complet d’une base de données très gourmande en mémoire pourra être conservé.

3. Vérifier un plantage réel avec un service isolé

Compiler un programme de test sans données métier

Écrivez ce programme minimal dans /tmp/crash-lab.c :

#include <stdlib.h>

int main(void)
{
    abort();
}

Créez un compte système dédié, puis compilez le programme. L’option -g conserve les informations de débogage et -O0 facilite l’examen de la pile d’appels du test :

sudo useradd --system --no-create-home --shell /usr/sbin/nologin crashlab
sudo install -d -m 0755 /usr/local/libexec
sudo gcc -g -O0 -o /usr/local/libexec/crash-lab /tmp/crash-lab.c

Si le compte existe déjà, vérifiez d’abord son usage au lieu de le recréer. Créez ensuite /etc/systemd/system/crash-lab.service :

[Unit]
Description=Isolated core dump capture test

[Service]
Type=oneshot
User=crashlab
ExecStart=/usr/local/libexec/crash-lab
LimitCORE=infinity
Restart=no

Ici, infinity lève uniquement la limite du processus pour ce service de test. Le collecteur reste soumis aux quotas de la section précédente. N’en faites pas une valeur par défaut globale pour tous les services.

sudo systemctl daemon-reload
sudo systemctl start crash-lab.service
sudo systemctl status crash-lab.service --no-pager
sudo coredumpctl --no-pager list /usr/local/libexec/crash-lab

Il est normal que la commande de démarrage signale un échec. Un événement de plantage correspondant à l’exécutable de test doit apparaître. Si ce n’est pas le cas, vérifiez dans l’ordre le mécanisme de prise en charge, les limites du service, les journaux du collecteur et l’espace disque. N’envoyez pas de signal de plantage à un processus en production pour effectuer ce contrôle.

4. Valider le fichier dump et les éléments de débogage

Relevez dans la liste le PID du test que vous venez d’effectuer. Saisissez-le dans un même shell administrateur, puis exportez le dump vers un répertoire privé dédié :

sudo -i
read -r -p 'Crash PID: ' CRASH_PID
umask 077
install -d -m 0700 /root/crash-evidence
coredumpctl info "$CRASH_PID"
coredumpctl dump "$CRASH_PID" --output=/root/crash-evidence/test.core
gdb -q -batch \
  -ex 'set pagination off' \
  -ex 'thread apply all bt' \
  /usr/local/libexec/crash-lab /root/crash-evidence/test.core
exit

Vérifiez d’abord l’heure de l’événement, l’exécutable, le signal et l’état du stockage, afin de ne pas récupérer le mauvais événement si le PID a été réutilisé. Le résultat attendu doit indiquer SIGABRT, avec une pile d’appels que l’on peut relier à la fonction main du programme de test. L’absence de code source pour les frames des bibliothèques système n’empêche pas de valider la chaîne de test.

Si seules les métadonnées sont disponibles, si le fichier ne peut pas être exporté ou si un avertissement de troncature apparaît, la collecte complète n’est pas validée. Le fait que coredumpctl répertorie un événement ne garantit pas non plus que le fichier externe existe encore.

Pour une application réelle, archivez également l’exécutable présent au moment du plantage, les bibliothèques partagées et les symboles de débogage correspondants. Un binaire mis à jour portant le même nom n’est pas le build d’origine. Utilisez readelf -n pour vérifier le Build ID, et consignez les versions des paquets ainsi que les identifiants de build.

N’utilisez pas directement bt full, qui affiche les variables locales. Commencez par la pile d’appels de base. Si l’examen de variables est réellement nécessaire, travaillez dans un environnement à accès restreint et contrôlez chaque élément du texte exporté. Conservez aussi le hachage des copies de binaires pour éviter qu’un remplacement des fichiers pendant l’analyse ne passe inaperçu.

5. Activer la collecte en production et vérifier son retrait

Pour activer la collecte sur un service applicatif, définissez LimitCORE dans un fichier drop-in propre à ce service. Exécutez daemon-reload, puis redémarrez le service dans le cadre d’un changement contrôlé. Une modification de configuration ne donne pas automatiquement de nouvelles limites aux processus déjà en cours : vérifiez celles du processus réel dans /proc/PID/limits.

La vérification de l’intégration doit couvrir au moins quatre points :

• Les redémarrages automatiques provoquent-ils une succession de dumps, et l’espace occupé par le répertoire reste-t-il maîtrisé ?
• Les quotas permettent-ils de conserver un fichier complet pour un processus applicatif représentatif ?
• Les archives de build fournissent-elles les binaires, bibliothèques et symboles de débogage correspondants ?
• Le répertoire d’export est-il accessible uniquement aux personnes autorisées, et les éléments collectés contiennent-ils des données sensibles ?

Une fois le test terminé, supprimez le fichier de service de test, le programme et son code source, puis exécutez daemon-reload et reset-failed. Traitez chaque dump de test séparément, à partir du chemin réel indiqué par coredumpctl info. N’utilisez pas de joker pour vider tout le répertoire des dumps.

Pour retirer cette politique de collecte, supprimez le fichier de configuration ajouté dans ce guide. Si vous devez rétablir le collecteur d’origine, faites-le par la configuration des paquets, puis vérifiez à nouveau kernel.core_pattern : ne reconstituez pas sa valeur de mémoire. Enfin, consignez une validation complète : l’événement de plantage est consultable, le fichier peut être exporté, la pile d’appels correspond au bon build et l’accès aux éléments est restreint. Vous disposerez ainsi de preuves de panne vérifiables, plutôt que d’une simple fonction activée sans contrôle.

Questions fréquentes