Wie wird der Speicherort (und Name) der Core-Dump-Datei festgelegt?

Ich bin auf CentOS 6 und versuche, Core-Dumps für eine Anwendung zu aktivieren, die ich entwickle. Ich habe getan:

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

in meinem Bash-Profil, aber ein Core-Dump wurde immer noch nicht generiert (in einem neuen Terminal).

Ich habe auch meine /etc/security/limits.conf so geändert, dass die weichen Grenzen für alle Benutzer Null sind.

Wie lege ich den Speicherort der auszugebenden Core-Dateien fest? Ich wollte den Speicherort angeben und den Zeitpunkt, zu dem der Speicherauszug erstellt wurde, als Teil des Dateinamens anhängen.

Um die Position der Core-Dumps in CentOS 6 festzulegen, können Sie sie bearbeiten /etc/sysctl.conf. Zum Beispiel, wenn Sie Core-Dumps in /var/crash:

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

Wo Variablen sind:

% e ist der Dateiname
% g ist die GID das Verfahren unter lief
% p wird die pid des Prozesses
% s wird das Signal , das der Dump verursacht
% t die Zeit ist der Mulden aufgetreten
% u ist die UID das Verfahren unter lief

Auch müssen Sie hinzufügen /etc/sysconfig/init

DAEMON_COREFILE_LIMIT='unlimited'

Wenden Sie jetzt neue Änderungen an:

$ sysctl -p

Aber es gibt eine Einschränkung auf diese Weise. Wenn der Kernelparameter kernel.core_pattern immer zurückgesetzt und beim Neustart auf die folgende Konfiguration überschrieben wird, auch wenn ein Wert manuell in angegeben wird /etc/sysctl.conf:

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

Kurz, wenn abrtd.serviceStarts kernel.core_patternautomatisch vom installierten System überschrieben werden abrt-addon-ccpp. Es gibt zwei Möglichkeiten, dies zu beheben:

1. Einstellmöglichkeit DumpLocationin der /etc/abrt/abrt.confKonfigurationsdatei. Das Zielverzeichnis kann durch Festlegen von DumpLocation = /var/crashin der /etc/abrt/abrt.confKonfigurationsdatei angegeben werden. sysctl kernel.core_patternDer angezeigte Wert ist derselbe, aber die eigentliche Kerndatei wird im Verzeichnis unter erstellt /var/crash.

   Auch wenn Sie SELinux aktiviert haben, müssen Sie Folgendes ausführen:

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

   Und zum Schluss nochmal neu starten abrtd.service:

   $ service abrtd.service restart
   

2. Beenden Sie abrtd service. kernel.core_patternwird nicht überschrieben. - (habe ich noch nie getestet).

Um einen Core-Dump auf Busybox zu generieren, können wir im Initialisierungsskript, das unsere ausführbare Datei ausführt, die folgenden Parameter hinzufügen. Wenn wir also Software initialisieren und Umgebungsvariablen exportieren, können wir die folgenden Zeilen auch in das Skript kopieren, um den Core zu sichern, falls ein Absturz auftritt.

Um den Speicherort der Core-Dumps in Busybox festzulegen, können Sie den Core-Dateipfad mithilfe des Proc-Dateisystems festlegen. Zum Beispiel, wenn Sie Core-Dumps in /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

Wo Variablen sind:

% e ist der Dateiname
% g ist die GID das Verfahren unter lief
% p wird die pid des Prozesses
% s wird das Signal , das der Dump verursacht
% t die Zeit ist der Mulden aufgetreten
% u ist die UID das Verfahren unter lief

Außerdem müssen Sie die Kerndateigröße festlegen. Mit dem folgenden Befehl wird die Kerndateigröße auf unbegrenzt festgelegt

ulimit -c unlimited

Um nun die für jeden Thread innerhalb eines Prozesses festgelegte Kerndateigröße zu überprüfen, können wir Folgendes verwenden

cat /proc/<PID>/limits

Die Ausgabe des obigen Befehls:

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      

Wie aus der obigen Ausgabe hervorgeht, ist die maximale Kerndateigröße auf unbegrenzt festgelegt.

Für weitere Informationen besuchen Sie bitte diesen Link. Debugging-Techniken für Linux-Anwendungen / Core-Dateien