Gunther Oracle APEX und Datenbank Wiki

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
=====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:

<code bash>

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'
</code>

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:

<code bash>
vi /etc/abrt/abrt-action-save-package-data.conf  

# auf yes setzen
ProcessUnpackaged = yes

</code>


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?==

<code bash>

sysctl -a|grep core_pattern

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

</code>
==== 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) <fc #800000>are not supported with Oracle Linux</fc>. ABRT packages and associated files, such as libreport, are included in the distribution to satisfy package dependencies, <fc #800000>but the features within these packages are not supported</fc>
...

===== Infos zur Core Dumps =====


=== Dump Verhalten optimieren ===

Zentrales Verzeichniss für Dumps einrichten wie /var/tmp/core und Kernel Parameter setzen

<code bash>

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

</code>

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
<code bash>

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

</code>


# auswerten mit gdb ( gdb <programm> <coredump> )

<code bash>

gdb /usr/bin/bash coredump_racdb01.pipperr.local_.11.1100.1100_1426632616_\!usr\!bin\!bash_bash.2779

</code>

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