Un processus qui crash sans laisser de fichier core derrière lui n’est pas forcément un mystère de débogage : sur la plupart des distributions modernes, ulimit -c (la taille maximale autorisée pour un core dump) vaut 0 par défaut, ce qui désactive silencieusement toute génération de core dump, sans le moindre message d’erreur au moment du crash.

Ce que ulimit -c contrôle réellement

ulimit -c fixe la taille maximale, en blocs, qu’un core dump est autorisé à atteindre. Une valeur de 0 ne limite pas la taille, elle interdit purement et simplement l’écriture du fichier : le processus crash normalement, le signal (SIGSEGV, par exemple) fait bien son travail, mais aucune trace n’est laissée pour l’analyse post-mortem.

# Valeur courante de la session shell active
ulimit -c
# 0

# Autorise des core dumps de taille illimitée
# pour la session shell courante uniquement
ulimit -c unlimited

Le piège : ce réglage ne survit pas à la session shell

ulimit -c unlimited appliqué dans un terminal ne change rien pour un service qui tourne déjà, ni pour un processus lancé par une autre voie que ce shell précis : la limite s’applique au shell courant et à tout ce qu’il lance ensuite, jamais rétroactivement, jamais globalement.

Le même piège systemd déjà rencontré ailleurs

Un service géré par systemd ignore /etc/security/limits.conf pour ses propres limites, exactement comme pour les limites de descripteurs de fichiers déjà documentées : la limite de core dump d’un service doit être définie directement dans son unit file, pas dans la configuration PAM traditionnelle qui ne s’applique qu’aux sessions de connexion.

# Dans le fichier unit du service (ou un override
# via systemctl edit), pas dans limits.conf
[Service]
LimitCORE=infinity

core_pattern : le second réglage qu’on oublie

Même avec ulimit -c unlimited correctement positionné, aucun fichier n’apparaît si /proc/sys/kernel/core_pattern pointe vers un gestionnaire externe (comme systemd-coredump sur la plupart des distributions modernes) sans que l’emplacement de stockage ne soit vérifié : le core dump existe bel et bien, mais pas forcément là où l’habitude fait chercher (./core dans le répertoire courant du processus).

# Sur une distribution avec systemd-coredump,
# les core dumps sont gérés et stockés ailleurs
cat /proc/sys/kernel/core_pattern
# |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e

# Liste et inspecte les core dumps collectés par systemd
coredumpctl list
coredumpctl gdb <PID>

À retenir

L’absence de fichier core après un crash pointe presque toujours vers ulimit -c à 0, la valeur par défaut sur la plupart des distributions, plutôt que vers une anomalie du crash lui-même. Un service géré par systemd ignore /etc/security/limits.conf pour cette limite exactement comme pour les descripteurs de fichiers, LimitCORE=infinity dans l’unit file étant le seul réglage qui compte réellement. Même avec la limite correctement configurée, core_pattern peut rediriger silencieusement les core dumps vers un gestionnaire comme systemd-coredump, coredumpctl devenant alors le point d’entrée à connaître plutôt qu’un fichier core cherché au mauvais endroit.