|
|
|
Your FairCom DB process unexpectedly dies. FairCom asks to see your core file for analysis. You look and it’s not there! This may occur for any of the following reasons:
The Redhat daemon ABRT, found on modern Redhat Linux systems, sets limits, in addition to ulimits, for core size, and and other problem application information. You should become familiar with this very useful utility suite. More importantly, ABRT is integrally tied to the Redhat package management system for automatic bug reporting. As such, this tool may remove unknown core files as they are dropped.
Why does the abrtd daemon delete recently created application core dumps?
Look for messages such as the following in your system logs:
Dec 12 3:19:22 hostname abrtd: Directory 'ctreedbs-13412346-1725' creation detected
Dec 12 3:19:22 hostname abrtd: Executable '/home/FairCom/servers/bin/ace/sql/ctreesql' doesn't belong to any package
Dec 12 3:19:22 hostname abrtd: Corrupted or bad crash /var/spool/abrt/ctreedbs-13412346-1725 (res:4), deleting
This is the case for applications not installed via the Redhat package management tool. System administrators should consider adding FairCom DB to the accepted list of applications to monitor. This is done with the following options In your /etc/abrt/abrt.conf configuration file:
This directive tells ABRT whether to process crashes in executables that do not belong to any package. The default setting is no.
This directive specifies whether ABRT's core catching hook should save a binary image to a core dump. It is useful when debugging crashes which occurred in binaries that were deleted. The default setting is no.
FairCom advises to also configure your ulimit to allow unlimited core files (-c) (within storage space availability, of course).
Linux systems using systemd must also set the following in /etc/systemd/coredump.conf
