Debian 13 : les core dumps remplissent votre disque — conservez la valeur de débogage, éliminez le superflu

octobre 7, 2025 • février 3, 2026 • Lecture : 30 min • Views: 13

Cet article vous a aidé ?

Vous ne vous trompez pas : un seul plantage peut déposer sur disque un core dump de la taille de votre RAM, et Debian 13 continuera volontiers à le faire jusqu’à
ce que votre nœud commence à échouer lors des écritures, que votre base de données passe en lecture seule, et que votre « petit problème d’app » devienne un incident
plateforme.

La solution n’est pas « désactiver les core dumps partout » (c’est comme ça qu’on se retrouve à déboguer à l’aveugle). La solution, c’est une politique : conserver
les dumps utiles, les garder peu de temps, les compresser quand c’est rentable, et faire en sorte que le système s’arrête avant d’« engloutir » la machine.

Ce qui se passe réellement quand les disques se remplissent de core dumps

Un core dump est un instantané de la mémoire d’un processus au moment où il est mort (généralement suite à un signal fatal). Il est utile parce qu’il contient
l’état que vous ne pourrez pas reconstruire plus tard : cadres de pile, objets du tas, états des threads, et parfois des données sensibles que vous préféreriez
ne pas stocker pendant des mois.

Sur Debian moderne, la gestion des core dumps passe typiquement par systemd-coredump. Le noyau détecte un processus qui plante, consulte
/proc/sys/kernel/core_pattern, et écrit soit un fichier directement soit pipe le core vers un gestionnaire. Avec systemd, ce gestionnaire peut
stocker le dump sous /var/lib/systemd/coredump/ et consigner les métadonnées dans le journal.

Le mode « disque plein » a quelques formes communes :

Boucles de crash à haute fréquence : un service redémarre, plante immédiatement, et recommence. Chaque plantage génère un nouveau dump.
Processus volumineux : JVM, navigateurs, runtimes de langage, ou tout ce qui a un gros heap. Un seul dump peut faire plusieurs dizaines de gigaoctets.
Stockage mal placé : les dumps atterrissent sur /var qui est sur votre plus petite partition (parce que 2009 a appelé).
Pas de rétention : vous avez supposé « systemd nettoiera ». Il le fera, mais seulement si c’est configuré et seulement selon son calendrier.
Sécurité et confidentialité : quelqu’un désactive globalement les dumps pour éviter la fuite de secrets, et vous perdez le seul artefact d’investigation que vous aviez.

Si vous faites du SRE assez longtemps, vous apprenez que les incidents « disque plein » ne sont pas des « problèmes de stockage ». Ce sont des problèmes de
plan de contrôle : pas de limites, pas de propriétaires, pas de politique. Les core dumps sont juste un moyen particulièrement efficace de rendre ces problèmes bruyants.

Une citation pour tout ce billet, parce que nous sommes des ingénieurs et que nous savons compter : Espérer n’est pas une stratégie. — idée paraphrasée souvent attribuée dans les cercles opérationnels.

Carnet de diagnostic rapide (premier / deuxième / troisième)

Quand un nœud vous prévient parce que le disque est à 99 % d’utilisation, vous ne commencez pas par la philosophie. Vous commencez par le triage. Voici la voie la plus rapide vers « qu’est-ce qui remplit le disque, pourquoi maintenant, et puis-je arrêter l’hémorragie sans détruire les preuves ? »

Premier : confirmer quel système de fichiers est plein et ce qui grossit

Identifier le point de montage plein et son appareil sous-jacent.
Confirmer s’il s’agit de /var, de / ou d’un volume dédié.
Trouver les principaux responsables par taille de répertoire, pas en devinant.

Deuxième : confirmer qu’il s’agit de core dumps et identifier la source du plantage

Vérifier la taille et les horodatages de /var/lib/systemd/coredump.
Utiliser coredumpctl pour trouver quel exécutable plante et à quelle fréquence.
Confirmer s’il s’agit d’une boucle de redémarrage (unit systemd instable) ou d’échecs isolés.

Troisième : appliquer une mesure palliative réversible, puis implémenter une politique

À court terme : limiter les dumps, désactiver temporairement pour le service en panne uniquement, ou déplacer le stockage.
Conserver un ou deux dumps représentatifs pour le débogage ; purger le reste une fois les preuves collectées.
Puis : configurer la rétention (systemd-coredump), les limites de taille et l’emplacement du stockage.

Blague n°1 (courte et pertinente) : Les core dumps sont comme les snacks de bureau — laissés sans gestion, ils s’étendent pour remplir tout l’espace disponible et vous laissent quand même sur votre faim.

Faits intéressants et courte histoire (parce que ce bazar a une généalogie)

Un peu de contexte aide à prendre de meilleures décisions. Voici des faits concrets qui importent opérationnellement :

Les core dumps pré-datent Linux : les systèmes Unix produisent des dumps de mémoire de processus depuis les années 1970 ; l’idée est plus ancienne que la plupart des runbooks de production.
« core » n’était pas métaphorique : les premières machines utilisaient la mémoire à noyau magnétique ; « core dump » signifiait littéralement vider le contenu de la mémoire core.
Les emplacements par défaut ont changé : les anciennes configurations écrivaient ./core dans le répertoire de travail ; les distributions modernes font souvent passer par des services système.
Le noyau décide si le dump est autorisé : les binaires setuid et certains contextes privilégiés peuvent être empêchés de produire des dumps pour des raisons de sécurité.
La taille du dump n’est pas juste « RAM utilisée » : les mappings mémoire, les huge pages et le comportement du runtime peuvent rendre les dumps plus grands ou plus petits que prévu.
La compression n’est pas gratuite : compresser des dumps de plusieurs Go consomme du CPU et peut voler des cycles à la récupération et à l’atténuation du paging.
Les métadonnées vivent séparément : avec systemd, vous obtenez des entrées de journal sur un dump même si le fichier de dump est absent ou plus tard tourné.
Le dump peut être pipé : core_pattern peut pipe vers un gestionnaire ; c’est pourquoi vous verrez un | au début du pattern.

Tâches pratiques : commandes, interprétation des sorties et décisions à prendre

C’est la partie qui paie les factures. Ci‑dessous des tâches réelles à exécuter sur Debian 13. Pour chacune : commande, sortie d’exemple, ce que cela signifie, et la décision
à en tirer. Faites-les dans l’ordre lors d’un incident, ou sélectionnez-en selon que vous connaissez déjà la forme du problème.

Tâche 1 : Confirmer quels systèmes de fichiers sont pleins

cr0x@server:~$ df -hT
Filesystem     Type   Size  Used Avail Use% Mounted on
/dev/sda2      ext4    40G   39G  320M  99% /
/dev/sda3      ext4    20G   19G  400M  98% /var
tmpfs          tmpfs  3.1G   12M  3.1G   1% /run

Sens : Ce sont / et /var qui souffrent, pas un volume de données quelconque. Cela pointe directement vers les logs, le cache des paquets,
les spools, et oui, les core dumps.

Décision : Concentrez-vous sur /var et arrêtez d’écrire là. Si /var est un système de fichiers séparé, vous pouvez souvent récupérer plus vite
en nettoyant /var sans déstabiliser tout l’OS.

Tâche 2 : Trouver les principaux répertoires sous /var par taille réelle

cr0x@server:~$ sudo du -xhd1 /var | sort -h
24M     /var/cache
180M    /var/log
1.1G    /var/tmp
17G     /var/lib
19G     /var

Sens : /var/lib est le poids lourd. C’est cohérent avec le stockage par systemd-coredump.

Décision : Approfondissez /var/lib avant de toucher aux logs ou aux caches. Votre gestion de l’incident s’améliore quand vous supprimez la bonne chose du premier coup.

Tâche 3 : Vérifier si systemd stocke des core dumps sur disque

cr0x@server:~$ sudo du -sh /var/lib/systemd/coredump
14G     /var/lib/systemd/coredump

Sens : Confirmé : des dumps sont présents et volumineux.

Décision : Ne supprimez pas tout de suite en masse. Identifiez d’abord le programme en cause et conservez au moins un dump représentatif.

Tâche 4 : Lister les core dumps récents et identifier le fautif

cr0x@server:~$ sudo coredumpctl list --no-pager | head
TIME                          PID  UID  GID SIG COREFILE  EXE
Mon 2025-12-29 10:02:41 UTC  9142  998  998  11 present   /usr/bin/myservice
Mon 2025-12-29 10:02:12 UTC  9136  998  998  11 present   /usr/bin/myservice
Mon 2025-12-29 10:01:43 UTC  9129  998  998  11 present   /usr/bin/myservice

Sens : Un binaire génère des dumps à répétition. Le signal 11 est une segfault, territoire classique de boucle de crash.

Décision : Contenir la boucle de crash. Conserver le dernier dump, puis arrêter l’accumulation de dumps supplémentaires.

Tâche 5 : Confirmer s’il s’agit d’une boucle de redémarrage systemd

cr0x@server:~$ systemctl status myservice.service --no-pager
● myservice.service - Example Service
     Loaded: loaded (/etc/systemd/system/myservice.service; enabled; preset: enabled)
     Active: activating (auto-restart) (Result: core-dump) since Mon 2025-12-29 10:02:42 UTC; 1s ago
    Process: 9142 ExecStart=/usr/bin/myservice (code=dumped, signal=SEGV)
   Main PID: 9142 (code=dumped, signal=SEGV)

Sens : systemd fait exactement ce que vous lui avez demandé : relancer le service et collecter les cores. Il remplit aussi votre disque.

Décision : Arrêter l’unité (ou ajuster la politique de redémarrage) pour arrêter l’hémorragie, puis préserver les artefacts pour le débogage.

Tâche 6 : Arrêter le service pour éviter de nouveaux dumps (mesure de triage)

cr0x@server:~$ sudo systemctl stop myservice.service
cr0x@server:~$ sudo systemctl is-active myservice.service
inactive

Sens : La boucle de crash s’est arrêtée, du moins sur ce nœud. L’utilisation du disque devrait cesser d’augmenter.

Décision : Si c’est un service de flotte, envisagez de rediriger le trafic ou de drainer ce nœud. Stabilisez d’abord ; déboguez ensuite.

Tâche 7 : Identifier les fichiers core les plus volumineux

cr0x@server:~$ sudo ls -lhS /var/lib/systemd/coredump | head
-rw------- 1 root root 6.8G Dec 29 10:02 core.myservice.998.3f7a7c1d2c7d4f2d9c9a0d3a9d1d8f0a.9142.1735466561000000.zst
-rw------- 1 root root 6.7G Dec 29 10:02 core.myservice.998.3f7a7c1d2c7d4f2d9c9a0d3a9d1d8f0a.9136.1735466532000000.zst
-rw------- 1 root root 6.7G Dec 29 10:01 core.myservice.998.3f7a7c1d2c7d4f2d9c9a0d3a9d1d8f0a.9129.1735466503000000.zst

Sens : Les dumps sont déjà compressés (notez .zst), et ils restent énormes. Cela indique que l’image mémoire du processus est volumineuse.

Décision : Conserver un dump (généralement le plus récent) pour analyse. Supprimer les doublons plus anciens une fois que vous avez une trace.

Tâche 8 : Extraire les détails du core dump sans le copier

cr0x@server:~$ sudo coredumpctl info 9142
           PID: 9142 (myservice)
           UID: 998 (myservice)
           GID: 998 (myservice)
        Signal: 11 (SEGV)
     Timestamp: Mon 2025-12-29 10:02:41 UTC
  Command Line: /usr/bin/myservice --config /etc/myservice/config.yaml
    Executable: /usr/bin/myservice
 Control Group: /system.slice/myservice.service
          Unit: myservice.service
       Storage: /var/lib/systemd/coredump/core.myservice.998.3f7a7c1d2c7d4f2d9c9a0d3a9d1d8f0a.9142.1735466561000000.zst (present)

Sens : Vous avez un mappage précis entre l’incident et l’artefact : unité, ligne de commande et chemin de stockage.

Décision : Capturez ces informations dans le canal/ticket d’incident avant de supprimer quoi que ce soit. C’est la piste pour le débogage ultérieur.

Tâche 9 : Obtenir la pile (nécessite des symboles de debug pour être vraiment utile)

cr0x@server:~$ sudo coredumpctl gdb 9142 -q --batch -ex "thread apply all bt"
[New LWP 9142]
Core was generated by `/usr/bin/myservice --config /etc/myservice/config.yaml'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f2f1a2b9c2a in memcpy () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x000055b8f2b1a2f0 in parse_packet (ctx=0x55b8f3c12000) at src/net/parse.c:217
#2  0x000055b8f2b19d71 in worker_loop () at src/worker.c:88
#3  0x00007f2f1a1691f5 in start_thread () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x00007f2f1a1e8b00 in clone () from /lib/x86_64-linux-gnu/libc.so.6

Sens : Vous avez une backtrace et un fichier/ligne, donc vous n’avez probablement pas besoin de 20 dumps identiques.

Décision : Conservez le core le plus récent + la trace. Supprimez le reste pour récupérer de l’espace disque. Si vous ne pouvez pas obtenir les symboles,
conservez un dump et concentrez-vous ensuite sur la collecte des symboles.

Tâche 10 : Vérifier la configuration actuelle de systemd-coredump

cr0x@server:~$ sudo systemd-analyze cat-config systemd/coredump.conf
# /etc/systemd/coredump.conf
[Coredump]
Storage=external
Compress=yes
ProcessSizeMax=8G
ExternalSizeMax=8G
MaxUse=16G
KeepFree=2G

Sens : Des limites existent, mais elles peuvent être trop généreuses pour la taille de votre /var (ou pour votre taux de plantage).

Décision : Resserrez MaxUse et augmentez KeepFree, ou déplacez le stockage vers un système de fichiers dédié.

Tâche 11 : Vérifier ce que le noyau fera des core dumps (core_pattern)

cr0x@server:~$ cat /proc/sys/kernel/core_pattern
|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e

Sens : Les cores sont pipés vers systemd-coredump, pas écrits directement par le noyau dans un chemin de fichier.

Décision : Corrigez la rétention via la configuration de systemd-coredump (et non en éditant un pattern de chemin en espérant un miracle).

Tâche 12 : Vérifier la limite globale de taille de core (ulimit) pour le shell courant

cr0x@server:~$ ulimit -c
unlimited

Sens : Au moins dans votre shell, la taille des cores n’est pas limitée. Pour les services, la limite effective peut provenir des paramètres de l’unité systemd.

Décision : Définissez des limites dans l’unité (préféré) ou via PAM limits pour les sessions interactives, selon le contexte.

Tâche 13 : Vérifier la limite de core appliquée à un processus de service en cours

cr0x@server:~$ pidof myservice
9210
cr0x@server:~$ grep -E '^Max core file size' /proc/9210/limits
Max core file size        unlimited            unlimited            bytes

Sens : Le service peut générer des dumps de taille maximale.

Décision : Si vous voulez « quelques » cores mais pas énormes, plafonnez à une taille qui préserve les piles (souvent quelques centaines de Mo) sans stocker tout le heap.

Tâche 14 : Confirmer si journald est aussi sous pression

cr0x@server:~$ journalctl --disk-usage
Archived and active journals take up 1.4G in the file system.

Sens : Les journaux ne sont pas le principal responsable ici, mais 1.4G peut encore compter sur un petit /var.

Décision : Ne « nettoyez » pas le journal en premier si les cores font 14G. Réglez le vrai problème d’abord.

Tâche 15 : Libérer de l’espace en sécurité en supprimant les anciens dumps après avoir préservé un

cr0x@server:~$ sudo coredumpctl list --no-pager | awk '/myservice/ {print $5}' | head
present
present
present
cr0x@server:~$ sudo rm -f /var/lib/systemd/coredump/core.myservice.*.9136.*.zst /var/lib/systemd/coredump/core.myservice.*.9129.*.zst
cr0x@server:~$ df -h /var
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda3        20G   12G  7.4G  62% /var

Sens : Vous avez gagné de l’air sans tout effacer à l’aveugle.

Décision : Maintenant, implémentez des limites adéquates pour que cela ne se reproduise pas. Les suppressions manuelles servent pour aujourd’hui, pas pour la semaine prochaine.

Une politique de rétention sensée pour Debian 13 (conserver la valeur, éliminer le superflu)

Vous voulez assez d’artefacts de crash pour répondre à : « que s’est‑il passé ? » Vous ne voulez pas une machine à remonter le temps de chaque crash du dernier trimestre.
Les core dumps sont des artefacts à fort signal et à coût élevé.

Une bonne politique a quatre volets :

Périmètre : quels processus peuvent produire des core dumps (tous ? seulement les services critiques ? seulement en staging ?).
Plafonds de taille : plafonds par processus et globaux qui correspondent à la réalité de vos disques.
Rétention : conserver une fenêtre courte (par temps et par espace), et tourner agressivement.
Accès & confidentialité : les core dumps peuvent contenir des identifiants, tokens, données clients et secrets décryptés. Traitez-les comme sensibles.

Voici la version opinionnée pour la plupart des flottes de production :

Activer les core dumps pour les services que vous déboguez réellement (généralement oui).
Limiter les dumps par processus à une taille qui préserve les backtraces et les piles de threads (souvent 256M–2G, selon le langage/runtime).
Conserver au maximum quelques gigaoctets par nœud ou par système de fichiers de dump, et garder une marge d’espace libre.
Préférer stocker les dumps sur un système de fichiers dédié (ou au moins un répertoire dédié avec quotas/limites prévisibles).
Expédier les métadonnées (pas les dumps) de manière centralisée. Ne déplacer les dumps hors hôte que lorsque vous décidez qu’ils sont nécessaires.

Si vous êtes tenté de désactiver complètement les core dumps, demandez‑vous : avez‑vous une télémétrie de crash reproductible, des backtraces symbolisées, et des étapes de repro déterministes ? Si oui, peut‑être. Sinon, vous choisissez des incidents plus longs.

Blague n°2 (la deuxième et la dernière) : Désactiver les core dumps partout, c’est comme retirer les détecteurs de fumée parce qu’ils font du bruit — silencieux, oui ; situation améliorée, non.

systemd-coredump : configuration adaptée à la production

Sur Debian 13, systemd est votre allié, mais seulement si vous lui dites ce que « suffisant » signifie. Le fichier est typiquement :
/etc/systemd/coredump.conf (et des drop-ins sous /etc/systemd/coredump.conf.d/).

Principaux réglages à connaître

Storage= Où les dumps vont : fichiers externes, journal, les deux, ou aucun.
Compress= Si les fichiers core doivent être compressés (souvent zstd). Utile, mais surveillez le CPU pendant les tempêtes de crash.
ProcessSizeMax= Taille max d’un dump de processus éligible au traitement.
ExternalSizeMax= Taille max d’un fichier core externe individuel sauvegardé.
MaxUse= Espace disque maximum que systemd-coredump peut consommer au total.
KeepFree= Combien d’espace libre garder sur le système de fichiers contenant les dumps.

Une base pratique pour un nœud avec un /var de 20–40G ressemble à :

MaxUse=2G à 6G selon la valeur que vous accordez aux dumps versus la disponibilité.
KeepFree=2G à 5G pour que journald, les mises à jour de paquets et le runtime normal ne meurent pas.
ExternalSizeMax=512M à 2G pour conserver des traces de pile sans toujours sauvegarder des heaps de plusieurs Go.

Vous n’avez pas à deviner. Choisissez une valeur plus petite que « qui remplit le disque », puis augmentez si vous manquez de données.

Exemple : resserrer la rétention immédiatement (et en sécurité)

cr0x@server:~$ sudo install -d /etc/systemd/coredump.conf.d
cr0x@server:~$ cat <<'EOF' | sudo tee /etc/systemd/coredump.conf.d/99-retention.conf
[Coredump]
Storage=external
Compress=yes
ExternalSizeMax=1G
MaxUse=4G
KeepFree=4G
EOF
cr0x@server:~$ sudo systemctl daemon-reload

Sens : Vous avez fixé des plafonds globaux stricts. Même si un service devient incontrôlable, le nœud continuera de respirer.

Décision : Si vous avez régulièrement besoin de heaps complets pour analyser des corruptions mémoire, augmentez ExternalSizeMax mais déplacez
les dumps hors de /var. Ne prétendez pas pouvoir avoir des dumps de 8G sur un système de fichiers de 20G et rester heureux.

Comment la rotation fonctionne réellement

systemd-coredump applique sa propre logique pour conserver/supprimer les dumps quand les limites sont atteintes. C’est bien, mais ce n’est pas instantané comme un quota.
Si vous êtes dans une boucle de crash, arrêtez quand même l’unité, sinon vous allez consommer CPU et I/O à générer des dumps qui seront immédiatement supprimés.

ulimit, core_pattern, et pourquoi « ça marchait sur mon portable » vous ment

La génération de core dumps comporte trois couches qui se confondent constamment :

Admissibilité du noyau : la génération de dumps est‑elle autorisée dans ce contexte de crash ?
Limites du processus : quelle est la taille max du core que le processus est autorisé à écrire ?
Gestionnaire de core : où va le core et quelle politique est appliquée après création ?

Les limites au niveau de l’unité systemd remplacent votre shell

Vous pouvez lancer ulimit -c dans un shell et vous sentir productif. Le service s’en fiche. Pour les services systemd, utilisez :
LimitCORE= dans le fichier d’unité ou un drop-in.

Exemple : plafonner les cores pour un service sans toucher au reste du nœud :

cr0x@server:~$ sudo systemctl edit myservice.service

cr0x@server:~$ cat /etc/systemd/system/myservice.service.d/override.conf
[Service]
LimitCORE=512M

cr0x@server:~$ sudo systemctl daemon-reload
cr0x@server:~$ sudo systemctl restart myservice.service

Sens : Même si le processus est énorme, le fichier dump ne pourra pas dépasser 512M. Souvent, c’est suffisant pour une trace exploitable.

Décision : Pour des services en boucle de crash, plafonnez immédiatement pour arrêter la croissance du disque tout en préservant une valeur de débogage.

core_pattern est le commutateur principal

Si /proc/sys/kernel/core_pattern pipe vers systemd-coredump, vos attentes « où sont les fichiers core ? » doivent changer.
Vous les trouverez sous la gestion de systemd, pas dans votre répertoire de travail.

Si votre organisation a des gestionnaires personnalisés (uploaders, filtres), validez-les. Un gestionnaire de core bogué peut échouer en ouvrant (laisser filer des dumps)
ou en échouant fermé (bloquer et retarder le chemin de sortie du processus qui plante). Aucun des deux cas n’est agréable.

Stratégie de stockage : où doivent vivre les core dumps (et où ils ne devraient pas)

Traitez les core dumps comme de mini‑sauvegardes de mémoire : volumineux, sensibles et parfois inestimables. Cela suggère quelques règles de stockage.

Règle 1 : Ne stockez pas les dumps sur un petit /var si vous pouvez l’éviter

Beaucoup d’images réservent encore une petite partition /var parce que ça semble « propre ». C’est aussi ainsi que vous vous retrouvez avec un OS incapable d’écrire son état pendant un incident. Si votre layout isole /var, planifiez où vont les dumps.

Règle 2 : Un système de fichiers dédié vaut mieux qu’un nettoyage héroïque

Le gain opérationnel est l’isolation : si les cores remplissent leur propre système de fichiers, le nœud peut toujours journaliser, mettre à jour des paquets, écrire l’état runtime et récupérer.
Vous pouvez monter un volume dédié sur /var/lib/systemd/coredump ou le bind‑monter.

Exemple : créer un point de montage et confirmer que c’est un système de fichiers séparé (la mise en place réelle dépend de votre environnement) :

cr0x@server:~$ sudo findmnt /var/lib/systemd/coredump
TARGET                       SOURCE    FSTYPE OPTIONS
/var/lib/systemd/coredump     /dev/sdb1 ext4   rw,relatime

Sens : Les dumps sont isolés de /var au sens large. Maintenant, votre pire cas devient « plus de dumps », pas « nœud mort ».

Règle 3 : Prévoir la confidentialité (les core dumps sont des données)

Les core dumps peuvent contenir :

des tokens API en mémoire
des payloads décryptés
des identifiants clients
des clés de chiffrement (oui, parfois)

Cela signifie : restreindre les permissions, limiter la rétention, et être délibéré sur qui peut exfiltrer des dumps pour débogage.
« Root peut lire » n’est pas une politique.

Règle 4 : Envisager de conserver les métadonnées centralement, pas les dumps

Dans de nombreuses organisations, le meilleur compromis est :

Conserver les core dumps localement pour une courte fenêtre.
Conserver seulement les métadonnées (horodatages, exécutable, unité, signal, backtrace) dans les enregistrements d’incident ou les logs centralisés.
Ne copier le dump hors hôte que lorsque vous avez décidé qu’il est nécessaire.

Cela évite de transformer votre pipeline de logs en un système de transport de données massives. Ces systèmes « fonctionnent toujours », jusqu’au moment où ils ne fonctionnent plus.

Trois micro-histoires d’entreprise issues des mines de crash-dumps

Micro‑histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a déployé une nouvelle image basée sur Debian vers un ensemble de nœuds API. L’image avait un joli schéma de partition : petit root, /var séparé,
et un volume de données propre pour l’état applicatif. Tout le monde se sentait mature.

Une semaine plus tard, un nœud a commencé à osciller. Pas toute la flotte—juste un. Il relançait sans cesse un service worker, et après un moment il a cessé de répondre aux déploiements.
Puis il a cessé de répondre aux connexions. Le nœud n’était pas mort ; il était simplement incapable d’écrire sur les emplacements qui comptaient.

La mauvaise hypothèse était simple : « Les core dumps vont sur le volume de données. » Quelqu’un avait vu des fichiers core dans un répertoire applicatif des années auparavant et avait supposé que c’était toujours la valeur par défaut. Sur cette image, systemd-coredump stockait les dumps dans /var/lib/systemd/coredump, et /var faisait 10–20G.

Chaque plantage générait un dump compressé de plusieurs Go. systemd redémarrait le service. D’autres dumps arrivaient. /var s’est rempli. Journald a commencé à perdre des messages. Les mises à jour de paquets ont échoué. Le nœud ne pouvait plus écrire assez d’état pour se remettre proprement.

La correction n’était pas sophistiquée : arrêter le service, garder un dump, supprimer les autres, et déplacer le stockage des core dumps vers un montage dédié. Puis resserrer KeepFree
pour que les futures tempêtes de crash ne puissent pas affamer l’OS. La correction plus profonde était culturelle : arrêter de supposer les valeurs par défaut et commencer à les vérifier avec des commandes qui retournent des faits.

Micro‑histoire 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation voulait « mieux déboguer », alors elle a activé largement les core dumps et augmenté la rétention. Ils ont aussi activé la compression et relevé les limites,
parce que « le stockage est bon marché ».

Ça allait… jusqu’à ce qu’une release introduise un crash rare dans un processus à haut débit. Le taux de plantage n’était pas énorme, mais pas non plus faible. Pendant les heures de pointe,
des cores étaient générés régulièrement, chacun de plusieurs gigaoctets même après compression.

Le retour de bâton est venu d’un angle que personne n’avait modélisé : la contention CPU pendant la récupération. Compresser de gros dumps demande du CPU. Quand les plantages ont commencé,
le système a passé une part mesurable de CPU à compresser des instantanés mémoire tout en essayant aussi d’alléger la charge, de redémarrer les services, et de servir le trafic.

Leur « optimisation pour le débogage » s’est traduite par des brownouts prolongés. Pas une panne totale, pire : une lente saignée où les requêtes expiraient et les retries amplifiaient la charge.
L’oncall voyait les cores et les incidents, mais la plateforme donnait l’impression d’avancer dans du sirop.

La politique finale fut plus nuancée : limiter la taille par service, et dans certains cas ne stocker que les métadonnées plus un dump minimal. Pour les rares analyses approfondies,
ils reproduiraient en staging avec les dumps complets activés. La valeur de débogage a augmenté, la douleur en incident a diminué.

Micro‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une société liée à la finance avait une habitude que personne ne célébrait : chaque unité critique avait un petit drop-in systemd définissant des limites de ressources,
incluant LimitCORE. C’était partie du « template d’unité doré », comme définir des timeouts et des politiques de redémarrage.

Une mise à jour d’une bibliothèque tierce a déclenché une segfault dans un service en arrière-plan sur un sous-ensemble de nœuds. Le service a planté, systemd l’a relancé, et oui,
des core dumps ont été générés. Mais ils étaient plafonnés à quelques centaines de mégaoctets.

Les nœuds sont restés sains. Les logs ont continué. Les déploiements ont pu continuer. L’incident a été pénible mais contrôlé. Les ingénieurs ont extrait un core, obtenu une backtrace,
corrélé le chemin de code défaillant, et rollbacké la librairie selon le planning.

Personne n’a eu de moment de héros. C’est le but. La limite ennuyeuse a permis à l’équipe de déboguer sans sacrifier la disponibilité. Cela a aussi évité au service sécurité de paniquer
à propos d’énormes instantanés mémoire sensibles qui s’accumulent sur les disques.

Erreurs courantes : symptôme → cause racine → correction

Voici les récidivistes. Chacun inclut une correction spécifique, pas un poster motivationnel.

Erreur 1 : « Le disque est plein, supprimez /var/log »

Symptôme : L’utilisation du disque monte rapidement ; les logs sont initialement blâmés ; vous supprimez des journaux et le problème revient le lendemain.

Cause racine : Des core dumps dans /var/lib/systemd/coredump sont le véritable volume de données.

Correction : Mesurez avec du, puis plafonnez et faites tourner les core dumps. Supprimez les dumps dupliqués seulement après avoir capturé au moins une backtrace.

Erreur 2 : « Désactiver les core dumps globalement »

Symptôme : Les incidents deviennent plus difficiles à déboguer ; les tickets « ça a crashé » traînent ; le blâme bascule vers « infra » parce qu’il n’y a plus de preuve.

Cause racine : Réponse brutale à la pression du disque ou aux préoccupations de confidentialité.

Correction : Gardez les cores activés mais limités. Utilisez LimitCORE par service, et MaxUse/KeepFree au niveau système.
Traitez les dumps comme sensibles et raccourcissez la rétention.

Erreur 3 : « Nous avons fixé MaxUse, donc nous sommes en sécurité »

Symptôme : Le disque atteint toujours 100 % pendant les tempêtes de plantage ; les nœuds deviennent instables.

Cause racine : Les limites n’agissent pas comme des quotas instantanés ; la boucle de crash continue de générer des données, et vous consommez aussi du CPU.

Correction : Arrêtez d’abord l’unité fautive. Ensuite configurez la rétention. Les limites ne remplacent pas la contention.

Erreur 4 : « Les cores sont petits parce qu’ils sont compressés »

Symptôme : Vous voyez .zst et supposez que tout va bien, jusqu’à ce que ce ne soit plus le cas.

Cause racine : Le ratio de compression varie énormément ; de gros heaps et des régions mappées donnent encore des dumps de plusieurs Go.

Correction : Plafonnez la taille. Vérifiez les tailles réelles des fichiers avec ls -lhS. Ne raisonnez pas à partir des extensions de fichier.

Erreur 5 : « Notre service ne peut pas être en boucle de crash ; on le remarquerait »

Symptôme : Soudain vous avez des dizaines de cores ; le service semble « globalement correct » parce qu’un load balancer masque un nœud défaillant.

Cause racine : Une défaillance partielle masquée par la redondance ; un nœud génère des cores silencieusement.

Correction : Alertez sur le taux de création de core dumps et sur les boucles de redémarrage des unités (Result: core-dump). Utilisez coredumpctl list pendant le triage.

Erreur 6 : « Nous avons déplacé les cores hors de /var, c’est réglé »

Symptôme : La partition de cores se remplit, et maintenant vous perdez les artefacts de débogage—toujours pas idéal.

Cause racine : Isolation sans rétention n’est que déplacer le feu.

Correction : Isolez et réglez MaxUse/KeepFree/ExternalSizeMax. Ajoutez de la surveillance.

Listes de contrôle / plan étape par étape

Checklist A : Pendant un incident actif de disque plein

Confirmer ce qui est plein : df -hT.
Identifier le répertoire qui grossit : sudo du -xhd1 /var | sort -h.
Confirmer que les core dumps sont le gros du volume : sudo du -sh /var/lib/systemd/coredump.
Identifier le fautif : sudo coredumpctl list.
Arrêter la boucle de crash : systemctl status ..., puis systemctl stop ... ou isoler le nœud.
Préserver un dump représentatif et les métadonnées : coredumpctl info PID.
Obtenir une backtrace si possible : coredumpctl gdb PID.
Supprimer les doublons pour récupérer du disque (de manière ciblée).
Fixer des limites de rétention immédiates (coredump.conf.d).
Reprendre ensuite le service dans des conditions contrôlées.

Checklist B : Durcissement après l’incident (la partie qui empêche les répétitions)

Créer ou confirmer un système de fichiers dédié pour les core dumps ou au moins suffisamment de marge sur /var.
Définir MaxUse et KeepFree en se basant sur vos nœuds les plus petits, pas les plus gros.
Définir ExternalSizeMax et/ou LimitCORE par service.
Définir qui peut accéder aux dumps et combien de temps ils persistent.
Assurer la disponibilité des symboles de debug là où vous analysez les dumps (sans déployer des toolchains complètes sur chaque nœud).
Ajouter des alertes sur :
- l’espace libre du système de fichiers de dump
- le taux de création de core dumps
- les boucles de redémarrage d’unités systemd avec résultat core-dump
Documenter la règle « garder un dump, purger les doublons » dans votre runbook.

FAQ

1) Dois‑je désactiver les core dumps en production ?

Habituellement non. Désactivez sélectivement si vous avez une raison solide (workloads sensibles avec contrôles stricts, ou vous disposez déjà d’une télémétrie de crash équivalente).
Préférez d’abord des plafonds de taille et des limites de rétention.

2) Où Debian 13 stocke‑t‑il les core dumps par défaut ?

Généralement sous /var/lib/systemd/coredump/ lorsque systemd-coredump est utilisé. Confirmez avec cat /proc/sys/kernel/core_pattern
et coredumpctl info.

3) Pourquoi mes fichiers core sont‑ils déjà compressés mais toujours énormes ?

Parce que la compression ne change pas le fait que vous capturez une grande image mémoire. De gros heaps, des fichiers mappés et certains motifs mémoire se compressent mal.
Plafonnez ExternalSizeMax et/ou LimitCORE.

4) Quelle est la manière la plus rapide d’identifier ce qui plante ?

sudo coredumpctl list montre l’exécutable et si un core file est présent. Combinez avec systemctl status pour repérer les boucles de redémarrage.

5) Puis‑je ne conserver que les métadonnées et pas le dump complet ?

Oui. Vous pouvez configurer le comportement de stockage pour ne conserver que les métadonnées, mais attention : quand vous aurez besoin d’un dump, vous ne l’aurez pas.
Un compromis courant est de garder des dumps petits et plafonnés plus les métadonnées.

6) Comment plafonner la taille des cores pour un service sans changer tout le nœud ?

Ajoutez un drop‑in systemd avec LimitCORE=... pour cette unité. C’est le point de contrôle opérationnel le plus propre pour les services.

7) Pourquoi le disque monte encore malgré MaxUse dans coredump.conf ?

Parce que vous pouvez toujours générer des cores rapidement pendant une boucle de crash, et l’application des limites n’est pas un quota instantané parfait. Arrêtez d’abord l’unité, puis ajustez la rétention. Les limites réduisent le bloat à l’état stable ; la contention arrête les tempêtes de crash.

8) Qu’en est‑il de la confidentialité et des secrets dans les core dumps ?

Supposez que les cores contiennent des secrets. Restreignez l’accès, raccourcissez la rétention et évitez d’envoyer les dumps largement. Traitez‑les comme des artefacts d’incident sensibles, pas comme des fichiers de logs.

9) Ai‑je besoin des symboles de debug sur chaque nœud de production ?

Pas nécessairement. Vous avez besoin d’un moyen fiable pour symboliser les piles quelque part. Beaucoup d’équipes gardent les symboles dans un environnement de debug dédié et n’extraient le dump nécessaire qu’au besoin (avec contrôles d’accès appropriés).

10) Est‑il sûr de supprimer des core dumps ?

Oui, après avoir préservé au moins un dump représentatif et capturé les métadonnées/backtraces. Le risque n’est pas la stabilité du système ; le risque est de perdre une valeur judiciaire. Soyez intentionnel : conservez un, supprimez les doublons.

Conclusion : prochaines étapes qui ne vous mordront pas plus tard

Les core dumps sont de l’or pour le débogage et de la kryptonite opérationnelle. Debian 13 vous donne les outils pour garder l’or et jeter la kryptonite, mais il ne le fera pas automatiquement.
Vous devez choisir des limites qui correspondent à vos disques et à votre tolérance aux incidents.

Faites ceci ensuite, dans cet ordre :

Sur un nœud, vérifiez où vont les dumps et quelle est leur taille : coredumpctl list, du -sh /var/lib/systemd/coredump.
Définissez la rétention globale : MaxUse et KeepFree dans un drop‑in coredump.
Définissez des plafonds par service pour les suspects habituels (gros heaps, composants sujets aux plantages) : LimitCORE.
Isolez le stockage si possible : dédiez un système de fichiers ou un montage pour les dumps.
Rendez‑le observable : alertez sur le taux de dumps et sur les boucles de redémarrage avec core dumps.

L’objectif n’est pas « ne jamais générer de core dump ». L’objectif est : quand quelque chose plante à 03:00, vous obtenez un artefact utile et un nœud qui redémarre.