Nommage des fichiers image de la mémoire

Par défaut, un fichier image de la mémoire s'appelle core, mais le fichier /proc/sys/kernel/core_pattern (depuis Linux 2.6 et 2.4.21) peut être configuré de manière à définir un motif qui sera utilisé pour le nommage des fichiers image de la mémoire. Le motif peut contenir des spécificateurs % qui sont remplacés par les valeurs suivantes lorsqu'une image de la mémoire est créée :

Un % isolé à la fin du motif est éliminé du nom de fichier de l'image mémoire, et il en sera de même pour un % suivi d'un caractère autre que ceux de la liste ci-dessus. Tous les autres caractères du motif conservent leur valeur littérale dans le nom de fichier de l'image mémoire. Un motif peut contenir des caractères « / », ils sont interprétés comme des délimiteurs pour les noms de répertoire. La taille maximale du nom de fichier de l'image mémoire résultant est de 128 octets (64 octets avant Linux 2.6.19). La valeur par défaut de ce nom de fichier est « core ». Afin d'assurer une rétrocompatibilité, si /proc/sys/kernel/core_pattern ne contient pas « %p » et si /proc/sys/kernel/core_uses_pid (voir ci-dessous) est différent de zéro, « .PID » est ajouté au nom de fichier de l'image mémoire.

Les chemins sont interprétés en tenant compte des paramètres actifs pour le processus qui a planté. Ces paramètres comprennent l'espace de noms montage du processus qui a planté (voir mount_namespaces(7)), son répertoire de travail actuel (déterminé à l'aide de getcwd(2)) et son répertoire racine (voir chroot(2)).

Depuis Linux 2.4, Linux procure aussi une méthode plus primitive pour contrôler le nom du fichier image de la mémoire. Si le fichier /proc/sys/kernel/core_uses_pid contient la valeur 0, le fichier image de la mémoire est tout simplement appelé core. Si ce fichier contient une valeur différente de zéro, le fichier image de la mémoire intégrera dans son nom le numéro d'identification du processus sous la forme core.PID.

À partir de Linux 3.6, si /proc/sys/fs/suid_dumpable a pour valeur 2 (« suidsafe »), le motif doit être soit un chemin absolu (commençant par le caractère « / », soit un tube, comme indiqué plus bas.

Tuber les vidages mémoire 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 caractère de ce fichier est le symbole du tube (|), le reste de la ligne est interprété comme une ligne de commande pour un programme de l'espace utilisateur (ou un script) à exécuter.

Depuis Linux 5.3.0, le modèle de tube est divisé en tenant compte des espaces en une liste d'arguments avant l'interprétation des paramètres du modèle. Avec les noyaux plus anciens, les paramètres du modèle sont interprétés en premier et la chaîne résultante est divisée en tenant compte des espaces en une liste d'arguments. Cela signifie qu'avec les noyaux plus anciens, les noms d'exécutable ajoutés par les paramètres de modèle %e et %E pouvaient être divisés en plusieurs arguments. Le gestionnaire de vidage mémoire doit donc définir le dernier argument avec les noms d'exécutable et s'assurer de « recoller » toutes les parties du nom de l'exécutable en tenant compte des espaces. Les noms d'exécutable qui contiennent plusieurs espaces ne sont pas correctement représentés dans les noyaux plus anciens, et dans ce cas, le gestionnaire de vidage mémoire devra utiliser des mécanismes permettant de déterminer le nom de l'exécutable.

Au lieu d'être écrit dans un fichier, le vidage mémoire est envoyé sur l'entrée standard du programme. Notez les points suivants :

• Le programme doit être indiqué avec un chemin d'accès absolu (ou un chemin relatif par rapport au répertoire racine, /) et doit immédiatement suivre le caractère « | ».
• Les arguments de la ligne de commande peuvent inclure tout spécificateur % indiqué plus haut. Par exemple, pour transmettre le PID du processus vidé, indiquez %p dans un argument.
• Le processus créé pour exécuter le programme s'exécute avec les utilisateur et groupe root.
• L'exécution en tant que root ne permet pas de contournement de sécurité exceptionnel. À ce titre, les LSM (comme SELinux) sont toujours actifs et peuvent empêcher le gestionnaire d'accéder aux détails du processus ayant planté à l'aide de /proc/pid.
• Le nom de chemin du programme est interprété en respectant l'espace de noms montage initial, car il est toujours exécuté dans ce contexte. Il n'est pas affecté par les paramètres du processus ayant planté (par exemple le répertoire racine, l'espace de noms montage et le répertoire de travail actuel).
• Le processus s'exécute dans les espaces de noms initiaux (PID, montage, utilisateur, etc.) et non dans les espaces de noms du processus ayant planté. On peut utiliser des spécificateurs comme %P pour trouver le répertoire /proc/pid correct et sonder/entrer les espaces de noms du processus ayant planté si nécessaire.
• Le processus démarre avec son répertoire de travail courant comme répertoire racine. Il est cependant possible de passer au répertoire de travail du processus de vidage en utilisant la valeur fournie par le spécificateur %P pour passer à l'emplacement du processus de vidage à l'aide de /proc/pid/cwd.
• Depuis Linux 2.6.24, il est possible de fournir au programme des arguments séparés par des espaces dans la ligne de commande (jusqu'à une longueur de ligne de 128 octets).
• La limite RLIMIT_CORE ne s'applique pas aux vidages mémoire tubés vers un programme à l'aide de ce mécanisme.

/proc/sys/kernel/core_pipe_limit

Lorsqu'on collecte des vidages mémoire à l'aide d'un tube vers un programme de l'espace utilisateur, il peut s'avérer utile pour le programme collecteur d'extraire les données à propos du processus ayant planté depuis le répertoire /proc/pid de ce dernier. Pour ce faire en toute sécurité, le noyau doit attendre que le programme collecteur de vidage mémoire se termine, de façon à ne pas supprimer prématurément les fichiers contenus dans le répertoire /proc/pid du processus ayant planté, ce qui a pour inconvénient de donner la possibilité à un programme de collecte défectueux de bloquer le vidage d’un processus planté en ne se terminant jamais.

Depuis Linux 2.6.32, on peut utiliser /proc/sys/kernel/core_pipe_limit pour limiter cette possibilité. La valeur contenue dans ce fichier définit le nombre de processus plantés simultanés qui peuvent être tubés en parallèle vers des programmes de l'espace utilisateur. Si cette valeur est dépassée, les processus plantés concernés seront consignés dans le journal du noyau et leurs vidages mémoires omis.

Une valeur de 0 dans ce fichier a une signification particulière. Elle indique qu'il n'y a pas de limite au nombre de processus qui peuvent être interceptés en parallèle, mais qu'aucune attente ne sera observée (autrement dit, le programme collecteur n'a aucune garantie d'accéder à /proc/<crashing-PID>). Par défaut, ce fichier contient la valeur 0.

Contrôler quelles projections seront écrites dans le vidage mémoire

Depuis Linux 2.6.23, le fichier /proc/pid/coredump_filter spécifique à Linux permet de contrôler quels segments de mémoire seront écrits dans le fichier image de la mémoire si un vidage mémoire est effectué pour le processus avec le PID correspondant.

La valeur dans ce fichier est un masque de bits des types de projection mémoire (consultez mmap(2)). Si un bit est positionné dans le masque, les projections mémoire du type correspondant sont vidées ; dans le cas contraire, elles ne le sont pas. Les bits dans ce fichier ont la signification suivante :

Par défaut, les bits suivants sont positionnés : 0, 1, 4 (si l'option de configuration du noyau CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS est activée) et 5. L'option d'amorçage coredump_filter permet de modifier ce réglage par défaut.

La valeur dans ce fichier est enregistrée en hexadécimal (la valeur par défaut est donc 33).

Les pages d'entrées-sorties projetées en mémoire telles que les tampons de trame ne sont jamais vidées, et les pages DSO virtuelles (vdso(7)) le sont toujours, quelle que soit la valeur de coredump_filter.

Un processus enfant créé avec fork(2) hérite de la valeur de coredump_filter de son parent ; la valeur de coredump_filter est préservée au travers d'un execve(2).

Il peut être utile de définir coredump_filter dans l'interpréteur de commande parent avant d'exécuter le programme ; par exemple :

$ echo 0x7 > /proc/self/coredump_filter
$ ./un_programme

Ce fichier n'existe que si le noyau a été compilé avec l'option de configuration CONFIG_ELF_CORE.

Vidages mémoire et systemd

Sur les systèmes qui utilisent systemd(1) comme cadriciel pour init, les vidages mémoire peuvent être écrits à un emplacement déterminé par systemd(1). À cet effet, systemd(1) utilise la fonctionnalité core_pattern qui permet de tuber les vidages mémoire vers un programme. Cela peut être vérifié en regardant si les vidages mémoires sont tubés 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 mémoire seront enregistrés à l'emplacement configuré pour systemd-coredump(8), en général sous la forme de fichiers compressés lz4(1) dans le répertoire /var/lib/systemd/coredump/. Pour lister les vidages mémoires qui ont été enregistrés 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 mémoire comprennent la date et l'heure du vidage, les PID, UID et GID du processus de vidage, le numéro du signal qui a déclenché le vidage et le chemin de l'exécutable qui était exécuté par le processus vidé. Plusieurs options de coredumpctl(1) permettent de déplacer le fichier image de la mémoire donné depuis l'emplacement de systemd(1) vers le fichier spécifié. Par exemple, pour extraire le vidage mémoire du PID 2955 montré plus haut dans un fichier nommé core dans le répertoire actuel, on peut utiliser :

$ coredumpctl dump 2955 -o core

Pour des détails plus exhaustifs, voir la page de manuel de coredumpctl(1).

Pour désactiver de manière permanente le mécanisme de systemd(1) qui archive les vidages mémoire et rétablir un fonctionnement plus proche du comportement traditionnel de Linux, on peut définir un contournement du mécanisme 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 redémarrage) en utilisant par exemple la commande suivante (qui inclut dans le nom des fichiers image de la mémoire le nom de l'exécutable et le numéro du signal qui a déclenché le vidage mémoire) :

# sysctl -w kernel.core_pattern="%e-%s.core"

Source du programme

/* core_pattern_pipe_test.c */
#define _GNU_SOURCE
#include <sys/stat.h>
#include <fcntl.h>
#include <limits.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#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 répertoire de travail actuel pour celui du
       processus qui a planté. */
    snprintf(cwd, PATH_MAX, "/proc/%s/cwd", argv[1]);
    chdir(cwd);
    /* Écrire la sortie dans le fichier "core.info" dans ce répertoire. */
    fp = fopen("core.info", "w+");
    if (fp == NULL)
        exit(EXIT_FAILURE);
    /* Afficher les arguments de ligne de commande passés au programme
       cible du tube configuré 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'entrée standard (le vidage mémoire). */
    tot = 0;
    while ((nread = read(STDIN_FILENO, buf, BUF_SIZE)) > 0)
        tot += nread;
    fprintf(fp, "Taille en octets du vidage mémoire : %zd\n", tot);
    fclose(fp);
    exit(EXIT_SUCCESS);
}