core(5) File Formats Manual core(5) NOM core -- Fichier image de la memoire DESCRIPTION L'action par defaut de certains signaux consiste a faire se terminer un processus et a produire un fichier image de la memoire (<< core dump file >>). C'est un fichier qui contient l'image memoire du processus au moment ou il s'est termine. Cette image peut etre utilisee dans un debogueur (par exemple, gdb(1)) pour etudier l'etat du programme au moment ou il s'est termine. Une liste des signaux provoquant la creation de cette image memoire se trouve dans signal(7). Un processus peut definir sa propre limite de ressource souple RLIMIT_CORE afin de definir une limite superieure a la taille du fichier image de la memoire qui sera cree s'il recoit un signal << core dump >> ; consultez getrlimit(2) pour davantage d'informations. Il y a diverses circonstances dans lesquelles un fichier image de la memoire (<< core dump >>) n'est pas produit : - Le processus ne possede pas les droits pour ecrire le fichier image de la memoire (par defaut, le fichier image de la memoire s'appelle core ou core.pid, ou pid est l'identifiant du processus qui a genere une image de la memoire. Il est cree dans le repertoire de travail en cours. Voir ci-dessous pour davantage d'informations sur les regles de nommage). L'ecriture du fichier image de la memoire echouera si le repertoire dans lequel il devrait etre ecrit n'est pas accessible en ecriture ou si un fichier avec le meme nom existe et n'est pas accessible en ecriture ou n'est pas un fichier ordinaire (par exemple, si c'est un repertoire ou un lien symbolique). - Un fichier (ordinaire et accessible en ecriture) avec le meme nom que celui qui serait utilise pour l'image de la memoire existe deja, mais il y a plusieurs liens physiques vers ce fichier. - Le systeme de fichiers dans lequel serait ecrit le fichier image de la memoire est plein, il n'a plus d'inoeud, il est monte en lecture seule ou l'utilisateur a atteint son quota pour le systeme de fichiers. - Le repertoire dans lequel le fichier image de la memoire doit etre cree n'existe pas. - Les limites de ressources RLIMIT_CORE (taille des fichiers << core >>) ou RLIMIT_FSIZE (taille des fichiers) pour un processus sont definies a zero ; consultez getrlimit(2) et la documentation de la commande ulimit de l'interpreteur de commande (limit dans csh(1)). RLIMIT_CORE sera cependant ignoree si le systeme est configure pour tuber les vidages memoire vers un programme. - Le binaire actuellement execute par le processus n'est pas accessible en lecture. Il s'agit d'une mesure de securite pour s'assurer qu'un executable dont le contenu n'est pas accessible en lecture ne produira pas de vidage memoire -- eventuellement lisible -- contenant une image de l'executable. - Le processus execute un programme set-user-ID (ou set-group-ID) dont le proprietaire (ou le groupe) est different de l'identifiant d'utilisateur (ou de groupe) reel du processus, ou le processus execute un programme qui possede des capacites de fichier (voir capabilities(7)). Consultez cependant la description de l'operation PR_SET_DUMPABLE de prctl(2), et la description du fichier /proc/sys/fs/suid_dumpable dans proc(5). - /proc/sys/kernel/core_pattern est vide et /proc/sys/kernel/core_uses_pid contient la valeur 0 (ces fichiers sont decrits plus loin). Notez que si /proc/sys/kernel/core_pattern est vide et si /proc/sys/kernel/core_uses_pid contient la valeur 1, les fichiers image de la memoire possederont des noms de la forme .pid, et que ces fichiers sont caches, a moins d'utiliser l'option -a de ls(1). - (Depuis Linux 3.7) Le noyau a ete compile sans l'option CONFIG_COREDUMP. De plus, le vidage memoire peut exclure des portions de l'espace d'adressage du processus si l'attribut MADV_DONTDUMP de madvise(2) est utilise. Sur les systemes qui utilisent systemd(1) comme cadriciel pour init, les vidages memoire peuvent etre ecrits a un emplacement determine par systemd(1). Voir plus loin pour plus de details. Nommage des fichiers image de la memoire Par defaut, un fichier image de la memoire s'appelle core, mais le fichier /proc/sys/kernel/core_pattern (depuis Linux 2.6 et 2.4.21) peut etre configure de maniere a definir un motif qui sera utilise pour le nommage des fichiers image de la memoire. Le motif peut contenir des specificateurs % qui sont remplaces par les valeurs suivantes lorsqu'une image de la memoire est creee : %% Caractere % unique %c Limite de ressource souple de la taille du fichier image de la memoire cree lors du plantage d'un processus (depuis Linux 2.6.24). %d Mode vidage (<< dump mode >>) -- identique a la valeur renvoyee par PR_GET_DUMPABLE de prctl(2) (depuis Linux 3.7). %e La valeur de comm du processus ou du thread, qui correspond en general au nom de l'executable (sans le chemin et tronque a un maximum de 15 caracteres), mais qui peut avoir ete modifiee en quelque chose de different ; voir les explications a propos de /proc/pid/comm et /proc/pid/task/tid/comm dans proc(5). %E Chemin d'acces de l'executable, ou les barres obliques << / >> sont remplacees par des points d'exclamation << ! >> (depuis Linux 3.0). %g GID numerique reel du processus dont l'image memoire a ete videe. %h Nom d'hote (identique a nodename renvoye par uname(2)). %i TID du thread qui a declenche le vidage memoire, tel qu'il est vu dans l'espace de noms du PID dans lequel le thread se trouve (depuis Linux 3.18). %I TID du thread qui a declenche le vidage memoire, tel qu'il est vu dans l'espace de noms du PID initial (depuis Linux 3.18). %p PID du processus dont l'image memoire a ete videe, tel qu'il est vu dans l'espace de noms du PID dans lequel le processus se trouve. %P PID du processus dont l'image memoire a ete videe, tel qu'il est vu dans l'espace des noms du PID initial (depuis Linux 3.12). %s Numero du signal ayant provoque le vidage memoire %t Heure du vidage memoire exprimee en secondes depuis l'Epoque, 1er janvier 1970 a 00:00:00 +0000 (UTC). %u UID numerique reel du processus << vide >>. Un % isole a la fin du motif est elimine du nom de fichier de l'image memoire, et il en sera de meme pour un % suivi d'un caractere autre que ceux de la liste ci-dessus. Tous les autres caracteres du motif conservent leur valeur litterale dans le nom de fichier de l'image memoire. Un motif peut contenir des caracteres << / >>, ils sont interpretes comme des delimiteurs pour les noms de repertoire. La taille maximale du nom de fichier de l'image memoire resultant est de 128 octets (64 octets avant Linux 2.6.19). La valeur par defaut de ce nom de fichier est << core >>. Afin d'assurer une retrocompatibilite, si /proc/sys/kernel/core_pattern ne contient pas << %p >> et si /proc/sys/kernel/core_uses_pid (voir ci-dessous) est different de zero, << .PID >> est ajoute au nom de fichier de l'image memoire. Les chemins sont interpretes en tenant compte des parametres actifs pour le processus qui a plante. Ces parametres comprennent l'espace de noms montage du processus qui a plante (voir mount_namespaces(7)), son repertoire de travail actuel (determine a l'aide de getcwd(2)) et son repertoire racine (voir chroot(2)). Depuis Linux 2.4, Linux procure aussi une methode plus primitive pour controler le nom du fichier image de la memoire. Si le fichier /proc/sys/kernel/core_uses_pid contient la valeur 0, le fichier image de la memoire est tout simplement appele core. Si ce fichier contient une valeur differente de zero, le fichier image de la memoire integrera dans son nom le numero d'identification du processus sous la forme core.PID. A partir de Linux 3.6, si /proc/sys/fs/suid_dumpable a pour valeur 2 (<< suidsafe >>), le motif doit etre soit un chemin absolu (commencant par le caractere << / >>, soit un tube, comme indique plus bas. Tuber les vidages memoire vers un programme Depuis le noyau 2.6.19, Linux prend en charge une syntaxe alternative pour le fichier /proc/sys/kernel/core_pattern. Si le premier caractere de ce fichier est le symbole du tube (|), le reste de la ligne est interprete comme une ligne de commande pour un programme de l'espace utilisateur (ou un script) a executer. Depuis Linux 5.3.0, le modele de tube est divise en tenant compte des espaces en une liste d'arguments avant l'interpretation des parametres du modele. Avec les noyaux plus anciens, les parametres du modele sont interpretes en premier et la chaine resultante est divisee en tenant compte des espaces en une liste d'arguments. Cela signifie qu'avec les noyaux plus anciens, les noms d'executable ajoutes par les parametres de modele %e et %E pouvaient etre divises en plusieurs arguments. Le gestionnaire de vidage memoire doit donc definir le dernier argument avec les noms d'executable et s'assurer de << recoller >> toutes les parties du nom de l'executable en tenant compte des espaces. Les noms d'executable qui contiennent plusieurs espaces ne sont pas correctement representes dans les noyaux plus anciens, et dans ce cas, le gestionnaire de vidage memoire devra utiliser des mecanismes permettant de determiner le nom de l'executable. Au lieu d'etre ecrit dans un fichier, le vidage memoire est envoye sur l'entree standard du programme. Notez les points suivants : - Le programme doit etre indique avec un chemin d'acces absolu (ou un chemin relatif par rapport au repertoire racine, /) et doit immediatement suivre le caractere << | >>. - Les arguments de la ligne de commande peuvent inclure tout specificateur % indique plus haut. Par exemple, pour transmettre le PID du processus vide, indiquez %p dans un argument. - Le processus cree pour executer le programme s'execute avec les utilisateur et groupe root. - L'execution en tant que root ne permet pas de contournement de securite exceptionnel. A ce titre, les LSM (comme SELinux) sont toujours actifs et peuvent empecher le gestionnaire d'acceder aux details du processus ayant plante a l'aide de /proc/pid. - Le nom de chemin du programme est interprete en respectant l'espace de noms montage initial, car il est toujours execute dans ce contexte. Il n'est pas affecte par les parametres du processus ayant plante (par exemple le repertoire racine, l'espace de noms montage et le repertoire de travail actuel). - Le processus s'execute dans les espaces de noms initiaux (PID, montage, utilisateur, etc.) et non dans les espaces de noms du processus ayant plante. On peut utiliser des specificateurs comme %P pour trouver le repertoire /proc/pid correct et sonder/entrer les espaces de noms du processus ayant plante si necessaire. - Le processus demarre avec son repertoire de travail courant comme repertoire racine. Il est cependant possible de passer au repertoire de travail du processus de vidage en utilisant la valeur fournie par le specificateur %P pour passer a l'emplacement du processus de vidage a l'aide de /proc/pid/cwd. - Depuis Linux 2.6.24, il est possible de fournir au programme des arguments separes par des espaces dans la ligne de commande (jusqu'a une longueur de ligne de 128 octets). - La limite RLIMIT_CORE ne s'applique pas aux vidages memoire tubes vers un programme a l'aide de ce mecanisme. /proc/sys/kernel/core_pipe_limit Lorsqu'on collecte des vidages memoire a l'aide d'un tube vers un programme de l'espace utilisateur, il peut s'averer utile pour le programme collecteur d'extraire les donnees a propos du processus ayant plante depuis le repertoire /proc/pid de ce dernier. Pour ce faire en toute securite, le noyau doit attendre que le programme collecteur de vidage memoire se termine, de facon a ne pas supprimer prematurement les fichiers contenus dans le repertoire /proc/pid du processus ayant plante, ce qui a pour inconvenient de donner la possibilite a un programme de collecte defectueux de bloquer le vidage d'un processus plante en ne se terminant jamais. Depuis Linux 2.6.32, on peut utiliser /proc/sys/kernel/core_pipe_limit pour limiter cette possibilite. La valeur contenue dans ce fichier definit le nombre de processus plantes simultanes qui peuvent etre tubes en parallele vers des programmes de l'espace utilisateur. Si cette valeur est depassee, les processus plantes concernes seront consignes dans le journal du noyau et leurs vidages memoires omis. Une valeur de 0 dans ce fichier a une signification particuliere. Elle indique qu'il n'y a pas de limite au nombre de processus qui peuvent etre interceptes en parallele, mais qu'aucune attente ne sera observee (autrement dit, le programme collecteur n'a aucune garantie d'acceder a /proc/). Par defaut, ce fichier contient la valeur 0. Controler quelles projections seront ecrites dans le vidage memoire Depuis Linux 2.6.23, le fichier /proc/pid/coredump_filter specifique a Linux permet de controler quels segments de memoire seront ecrits dans le fichier image de la memoire si un vidage memoire est effectue pour le processus avec le PID correspondant. La valeur dans ce fichier est un masque de bits des types de projection memoire (consultez mmap(2)). Si un bit est positionne dans le masque, les projections memoire du type correspondant sont videes ; dans le cas contraire, elles ne le sont pas. Les bits dans ce fichier ont la signification suivante : bit 0 Vider les projections privees anonymes. bit 1 Vider les projections partagees anonymes. bit 2 Vider les projections privees sauvegardees sur fichier. bit 3 Vider les projections partagees sauvegardees sur fichier. bit 4 (depuis Linux 2.6.24) Vider les en-tetes ELF. bit 5 (depuis Linux 2.6.28) Vider les pages privees volumineuses. bit 6 (depuis Linux 2.6.28) Vider les pages partagees volumineuses. bit 7 (depuis Linux 4.4) Vider les pages DAX privees. bit 8 (depuis Linux 4.4) Vider les pages DAX partagees. Par defaut, les bits suivants sont positionnes : 0, 1, 4 (si l'option de configuration du noyau CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS est activee) et 5. L'option d'amorcage coredump_filter permet de modifier ce reglage par defaut. La valeur dans ce fichier est enregistree en hexadecimal (la valeur par defaut est donc 33). Les pages d'entrees-sorties projetees en memoire telles que les tampons de trame ne sont jamais videes, et les pages DSO virtuelles (vdso(7)) le sont toujours, quelle que soit la valeur de coredump_filter. Un processus enfant cree avec fork(2) herite de la valeur de coredump_filter de son parent ; la valeur de coredump_filter est preservee au travers d'un execve(2). Il peut etre utile de definir coredump_filter dans l'interpreteur de commande parent avant d'executer le programme ; par exemple : $ echo 0x7 > /proc/self/coredump_filter $ ./un_programme Ce fichier n'existe que si le noyau a ete compile avec l'option de configuration CONFIG_ELF_CORE. Vidages memoire et systemd Sur les systemes qui utilisent systemd(1) comme cadriciel pour init, les vidages memoire peuvent etre ecrits a un emplacement determine par systemd(1). A cet effet, systemd(1) utilise la fonctionnalite core_pattern qui permet de tuber les vidages memoire vers un programme. Cela peut etre verifie en regardant si les vidages memoires sont tubes vers le programme systemd-coredump(8) : $ cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %e Dans ce cas, les vidages memoire seront enregistres a l'emplacement configure pour systemd-coredump(8), en general sous la forme de fichiers compresses lz4(1) dans le repertoire /var/lib/systemd/coredump/. Pour lister les vidages memoires qui ont ete enregistres par systemd-coredump(8), on peut utiliser coredumpctl(1) : $ coredumpctl list | tail -5 Wed 2017-10-11 22:25:30 CEST 2748 1000 1000 3 present /usr/bin/sleep Thu 2017-10-12 06:29:10 CEST 2716 1000 1000 3 present /usr/bin/sleep Thu 2017-10-12 06:30:50 CEST 2767 1000 1000 3 present /usr/bin/sleep Thu 2017-10-12 06:37:40 CEST 2918 1000 1000 3 present /usr/bin/cat Thu 2017-10-12 08:13:07 CEST 2955 1000 1000 3 present /usr/bin/cat Les informations contenues dans tout vidage memoire comprennent la date et l'heure du vidage, les PID, UID et GID du processus de vidage, le numero du signal qui a declenche le vidage et le chemin de l'executable qui etait execute par le processus vide. Plusieurs options de coredumpctl(1) permettent de deplacer le fichier image de la memoire donne depuis l'emplacement de systemd(1) vers le fichier specifie. Par exemple, pour extraire le vidage memoire du PID 2955 montre plus haut dans un fichier nomme core dans le repertoire actuel, on peut utiliser : $ coredumpctl dump 2955 -o core Pour des details plus exhaustifs, voir la page de manuel de coredumpctl(1). Pour desactiver de maniere permanente le mecanisme de systemd(1) qui archive les vidages memoire et retablir un fonctionnement plus proche du comportement traditionnel de Linux, on peut definir un contournement du mecanisme de systemd(1) en utilisant quelque chose du genre : # echo "kernel.core_pattern=core.%p" > \ /etc/sysctl.d/50-coredump.conf # /lib/systemd/systemd-sysctl On peut aussi modifier le core_pattern temporairement (jusqu'au prochain redemarrage) en utilisant par exemple la commande suivante (qui inclut dans le nom des fichiers image de la memoire le nom de l'executable et le numero du signal qui a declenche le vidage memoire) : # sysctl -w kernel.core_pattern="%e-%s.core" NOTES La commande gdb(1) gcore permet d'obtenir une image memoire d'un processus en cours d'execution. Jusqu'a Linux 2.6.27 inclus, si un processus multithreade (ou plus precisement, un processus qui partage son espace memoire avec un autre processus parce que cree avec l'indicateur CLONE_VM de clone(2)) cree une image memoire, l'identifiant du processus (PID) est toujours ajoute au nom du fichier image de la memoire, a moins que l'identifiant du processus ne fasse deja partie du nom de fichier de par la presence d'une specification %p dans /proc/sys/kernel/core_pattern (cela s'avere principalement utile lors de l'utilisation de l'implementation obsolete LinuxThreads pour laquelle chaque thread d'un processus a son propre PID). EXEMPLES Le programme ci-dessous montre l'utilisation de la syntaxe de tubage dans le fichier /proc/sys/kernel/core_pattern. La session de l'interpreteur de commande suivante montre l'utilisation de ce programme (compile pour creer un executable nomme core_pattern_pipe_test) : $ cc -o core_pattern_pipe_test core_pattern_pipe_test.c $ su Password: # echo "|$PWD/core_pattern_pipe_test %p UID=%u GID=%g sig=%s" > \ /proc/sys/kernel/core_pattern # exit $ sleep 100 ^\ # taper control-backslash Quit (core dumped) $ cat core.info argc=5 argc[0]= argc[1]=<20575> argc[2]= argc[3]= argc[4]= Total bytes in core dump: 282624 Source du programme /* core_pattern_pipe_test.c */ #define _GNU_SOURCE #include #include #include #include #include #include #define BUF_SIZE 1024 int main(int argc, char *argv[]) { ssize_t nread, tot; char buf[BUF_SIZE]; FILE *fp; char cwd[PATH_MAX]; /* Changer le repertoire de travail actuel pour celui du processus qui a plante. */ snprintf(cwd, PATH_MAX, "/proc/%s/cwd", argv[1]); chdir(cwd); /* Ecrire la sortie dans le fichier "core.info" dans ce repertoire. */ fp = fopen("core.info", "w+"); if (fp == NULL) exit(EXIT_FAILURE); /* Afficher les arguments de ligne de commande passes au programme cible du tube configure dans core_pattern. */ fprintf(fp, "argc=%d\n", argc); for (size_t j = 0; j < argc; j++) fprintf(fp, "argc[%zu]=<%s>\n", j, argv[j]); /* Compter les octets sur l'entree standard (le vidage memoire). */ tot = 0; while ((nread = read(STDIN_FILENO, buf, BUF_SIZE)) > 0) tot += nread; fprintf(fp, "Taille en octets du vidage memoire : %zd\n", tot); fclose(fp); exit(EXIT_SUCCESS); } VOIR AUSSI bash(1), coredumpctl(1), gdb(1), getrlimit(2), mmap(2), prctl(2), sigaction(2), elf(5), proc(5), pthreads(7), signal(7), systemd-coredump(8) TRADUCTION La traduction francaise de cette page de manuel a ete creee par Christophe Blaess , Stephan Rafin , Thierry Vignaud , Francois Micaux, Alain Portal , Jean-Philippe Guerard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas Huriaux , Nicolas Francois , Florentin Duneau , Simon Paillard , Denis Barbier , David Prevot , Cedric Boutillier , Frederic Hantrais et Lucien Gentis Cette traduction est une documentation libre ; veuillez vous reporter a la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITE LEGALE. Si vous decouvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message a . Pages du manuel de Linux 6.06 31 octobre 2023 core(5)