Comment définir l'emplacement (et le nom) du fichier de vidage principal?

Je suis sur CentOS 6, j'essaye d'activer les vidages mémoire pour une application que je développe. J'ai mis:

ulimit -H -c unlimited >/dev/null
ulimit -S -c unlimited >/dev/null

dans mon profil bash, mais un vidage de mémoire n'a toujours pas généré (dans un nouveau terminal).

J'ai également changé mon /etc/security/limits.conf afin que les limites logicielles soient nulles pour tous les utilisateurs.

Comment définir l'emplacement des fichiers principaux à afficher? Je voulais spécifier l'emplacement et ajouter l'heure à laquelle le vidage a été généré, dans le cadre du nom de fichier?

Pour définir l'emplacement des vidages mémoire dans CentOS 6, vous pouvez les modifier /etc/sysctl.conf. Par exemple, si vous voulez des vidages mémoire dans /var/crash:

kernel.core_pattern = /var/crash/core-%e-%s-%u-%g-%p-%t

Où les variables sont:

% e est le nom de fichier
% g est le gid sous lequel le processus s'exécutait sous
% p est le pid du processus
% s est le signal qui a provoqué le vidage
% t est le moment où le vidage s'est produit
% u est l'uid sous lequel le processus s'exécutait

Vous devez également ajouter /etc/sysconfig/init

DAEMON_COREFILE_LIMIT='unlimited'

Appliquez maintenant de nouvelles modifications:

$ sysctl -p

Mais il y a une mise en garde de cette façon. Si le paramètre du noyau kernel.core_pattern est toujours réinitialisé et remplacé au redémarrage dans la configuration suivante même lorsqu'une valeur est spécifiée manuellement dans /etc/sysctl.conf:

|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e

Bref quand les abrtd.servicedémarrages kernel.core_patternsont écrasés automatiquement par le système installé abrt-addon-ccpp. Il existe deux façons de résoudre ce problème:

1. DumpLocationOption de paramétrage dans le /etc/abrt/abrt.conffichier de configuration. Le répertoire de destination peut être spécifié en définissant DumpLocation = /var/crashdans le /etc/abrt/abrt.conffichier de configuration, et sysctl kernel.core_patternla valeur affichée est la même, mais en réalité le fichier principal sera créé dans le répertoire sous /var/crash.

   De plus, si SELinux est activé, vous devez exécuter:

   $ semanage fcontext -a -t public_content_rw_t "/var/crash(/.*)?"  
   $ setsebool -P abrt_anon_write 1
   

   Et enfin redémarrez abrtd.service:

   $ service abrtd.service restart
   

2. Arrêtez le service abrtd. kernel.core_patternne sera pas écrasé. - (je n'ai jamais testé).

Pour générer le vidage de mémoire sur Busybox, nous pouvons ajouter les paramètres ci-dessous dans le script d'initialisation qui exécute notre exécutable. Donc, chaque fois que nous initialisons le logiciel et exportons des variables d'environnement, nous pouvons copier les lignes ci-dessous dans le script ainsi que vider le noyau au cas où nous verrions un plantage.

Pour définir l'emplacement des vidages mémoire dans Busybox, vous pouvez définir le chemin du fichier mémoire à l'aide du système de fichiers proc. Par exemple, si vous souhaitez des vidages de mémoire dans /tmp/crash/corefiles:

mkdir -p /tmp/crash/corefiles
chmod 775 /tmp/crash/corefiles
echo "/tmp/crash/corefiles/%e.%s.core" > /proc/sys/kernel/core_pattern

Où les variables sont:

% e est le nom de fichier
% g est le gid sous lequel le processus s'exécutait sous
% p est le pid du processus
% s est le signal qui a provoqué le vidage
% t est le moment où le vidage s'est produit
% u est l'uid sous lequel le processus s'exécutait

En outre, vous devez définir la taille du fichier principal, la commande ci-dessous définit la taille du fichier principal sur illimité

ulimit -c unlimited

Maintenant, pour vérifier la taille de fichier de base définie pour chaque thread dans un processus, nous pouvons vérifier en utilisant

cat /proc/<PID>/limits

La sortie de la commande ci-dessus:

Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        unlimited            unlimited            bytes     
Max open files            10000                10000                files     
Max address space         unlimited            unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             31868                31868                processes 
Max locked memory         65536                65536                bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       31868                31868                signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us      

Comme nous pouvons le voir sur la sortie ci-dessus, la taille maximale du fichier core est définie sur illimitée.

Pour plus d'informations, veuillez visiter ce lien. Techniques de débogage d'applications Linux / Fichiers de base