Ü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)

sysctl -a|grep core_pattern
 
kernel.core_pattern = |/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e

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 …

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.

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 <programm> <coredump> )

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

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