=====Abrtd - Red Hat Automatic Bug Reporting Tool - Kernel Dumps - RedHat Linux 6 ===== Über ein Problem unter einem RAC Cluster auf diese Linux Dämon unter RedHat Linux 6 gestoßen: Mar 05 15:37:00 racdb01 abrt[83534]: Saved core dump of pid 83533 (/opt/oracle/product/11.2.0.4/db_home1/bin/oracle) to /var/spool/abrt/ccpp-2015-03-05-15:37:00-83533 (3837952 bytes) Mar 05 15:37:00 racdb01 abrtd: Directory 'ccpp-2015-03-05-15:37:00-83533' creation detected Mar 05 15:37:00 racdb01 abrtd: Executable '/opt/oracle/product/11.2.0.4/db_home1/bin/oracle' doesn't belong to any package Mar 05 15:37:00 racdb01 abrtd: 'post-create' on '/var/spool/abrt/ccpp-2015-03-05-15:37:00-83533' exited with 1 Mar 05 15:37:00 racdb01 abrtd: Corrupted or bad directory /var/spool/abrt/ccpp-2015-03-05-15:37:00-83533, deleting Mar 05 15:37:01 racdb01 abrt[83604]: Not dumping repeating crash in '/opt/oracle/product/11.2.0.4/db_home1/bin/oracle' Mar 05 15:37:02 racdb01 abrt[83661]: Not dumping repeating crash in '/opt/oracle/product/11.2.0.4/db_home1/bin/oracle' Warum wird nun der Dump nicht geschrieben? Wichtig ist die Zeile "Executable '/opt/oracle/product/11.2.0.4/db_home1/bin/oracle' doesn't belong to any package", per default schreibt der **Abrtd** nur Dumps für mit yum/rpm installierte Produkte auf dem System. Lösung: vi /etc/abrt/abrt-action-save-package-data.conf # auf yes setzen ProcessUnpackaged = yes Support Node zu diesen Thema: * Abrtd Daemon Delete Recently Created Application Core Dumps- Corrupted or Bad Dump /var/spool/abrt/ccpp-XXX11076 (res:2), deleting (Doc ID 1943338.1) == Wo wird der Core abgelegt?== sysctl -a|grep core_pattern kernel.core_pattern = |/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e ==== Oracle Linux 7 ==== Aus der Oracle Dokumentation => http://docs.oracle.com/cd/E52668_01/E53499/html/ol7-fixed-known-issues.html ... the daemons and features provided by the Red Hat Automatic Bug Reporting Tool (ABRT) are not supported with Oracle Linux. ABRT packages and associated files, such as libreport, are included in the distribution to satisfy package dependencies, but the features within these packages are not supported ... ===== Infos zur Core Dumps ===== === Dump Verhalten optimieren === Zentrales Verzeichniss für Dumps einrichten wie /var/tmp/core und Kernel Parameter setzen mkdir /var/tmp/core chmod 777 /var/tmp/core vi /etc/sysctl.conf kernel.core_uses_pid=1 kernel.panic_on_oops = 1 kernel.core_pattern = /var/tmp/core/coredump_%h_.%s.%u.%g_%t_%E_%e fs.suid_dumpable=1 sysctl -p Core File Parameter: * %p: pid * %%: output one '%' * %u: uid - user id * %g: gid - group id * %s: signal number * %t: UNIX time of dump * %h: hostname * %e: executable filename * %E: pathname of executable * %h: hostname fs.suid_dumpable * 0 - (default) - traditional behaviour. Any process which has changed privilege levels or is execute only will not be dumped * 1 - (debug) - all processes dump core when possible. The core dump is owned by the current user and no security is applied. This is intended for system debugging situations only. * 2 - (suidsafe) - any binary which normally not be dumped is dumped readable by root only. This allows the end user to remove such a dump but not access it directly. For securityreasons core dumps in this mode will not overwrite one another or other files. This mode is appropriate when adminstrators are attempting to debug problems in a normal environment. Auf die aktuellen Limit Einstellungen achten, falls "ulimit -c" = "0" werden auch keine Dumps erzeugt. ==testen== Als Oracle User anmelden und Dump verursachen, testen ob die Datei da ist su - oracle #ulimit ulimit -c unlimited => beliebig gross #Core dump der Bash Session erzeugen kill -s SIGSEGV $$ Segmentation fault (core dumped) #nun wieder root und testen: cd /var/tmp/core/ ls coredump_racdb01.pipperr.local_.11.1100.1100_1426632616_!usr!bin!bash_bash.2779 #Datum aus dem Core anzeigen mit: date -d @1426632616 Tue Mar 17 23:50:16 CET 2015 # auswerten mit gdb ( gdb ) gdb /usr/bin/bash coredump_racdb01.pipperr.local_.11.1100.1100_1426632616_\!usr\!bin\!bash_bash.2779 siehe => http://man7.org/linux/man-pages/man5/core.5.html ==Kdump zur Analyse== siehe * https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/pdf/Kernel_Crash_Dump_Guide/Red_Hat_Enterprise_Linux-7-Kernel_Crash_Dump_Guide-en-US.pdf