Enable FairCom DB Core Files on Linux
Missing core files for the faircom process. With modern Linux distributions, you will need to enable core files, and configure the abrtd Linux deamon to allow the FairCom DB server process core to be saved by the OS.
Uh-oh...it happens. Perhaps you ran shy of memory. Or worse, you violate FairCom’s cardinal rule of transaction logs: You ran out of drive space. Your FairCom DB process unexpectedly dies. FairCom asks to see your core file for analysis. You go to look and...it’s not there!
The Redhat daemon ABRT, Automatic Bug Reporting Tool, (abrtd process) is usually at play in this situation.
Automatic Bug Reporting Tool (ABRT)
This tool, 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:
- ProcessUnpackaged = yes/no
This directive tells ABRT whether to process crashes in executables that do not belong to any package. The default setting is no.
- SaveBinaryImage = yes/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).
systemd includes its own set of additional limits configured in: /etc/systemd/coredump.conf
ProcessSizeMax and ExternalSizeMax should be set appropriately for normal database process size.