How to set the core dump file location (and name)?

I am on CentOS 6, trying to enable core dumps for an application I am developing. I have put:

ulimit -H -c unlimited >/dev/null
ulimit -S -c unlimited >/dev/null

in to my bash profile, but a core dump still did not generate (in a new terminal).

I have also changed my /etc/security/limits.conf so that the soft limits is zero for all users.

How do I set the location of the core files to be output? I wanted to specify the location and append the time the dump was generated, as part of the file name?

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

To set location of core dumps in CentOS 6 you can edit /etc/sysctl.conf. For example if you want core dumps in /var/crash:

kernel.core_pattern = /var/crash/core-%e-%s-%u-%g-%p-%t

Where variables are:

%e is the filename
%g is the gid the process was running under
%p is the pid of the process
%s is the signal that caused the dump
%t is the time the dump occurred
%u is the uid the process was running under

Also you have to add /etc/sysconfig/init

DAEMON_COREFILE_LIMIT='unlimited'

Now apply new changes:

$ sysctl -p

But there is a caveat whit this way. If the kernel parameter kernel.core_pattern is always reset and overwritten at reboot to the following configuration even when a value is manually specified in /etc/sysctl.conf:

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

In short when abrtd.service starts kernel.core_pattern is overwritten automatically by the system installed abrt-addon-ccpp. There are two ways to resolve this:

1. Setting DumpLocation option in the /etc/abrt/abrt.conf configuration file. The destination directory can be specified by setting DumpLocation = /var/crash in the /etc/abrt/abrt.conf configuration file, and sysctl kernel.core_pattern‘s displayed value is a same but actually core file will be created to the directory under /var/crash.

   Also if you have SELinux enabled you have to run:
   

   $ semanage fcontext -a -t public_content_rw_t "/var/crash(/.*)?"  
   $ setsebool -P abrt_anon_write 1

   
   And finally restart abrtd.service:
   

   $ service abrtd.service restart

2. Stop abrtd service. kernel.core_pattern will not be overwritten. – (I’ve never tested).

Method 2

To generate core dump on Busybox we can add below parameters in initialize script which runs our executable. So whenever we initialize software and export environment variables we can copy the below lines to the script as well to dump core in case if we see any crash.

To set the location of core dumps in Busybox you can set core file path using the proc file system. For example, if you want core dumps in /tmp/crash/corefiles:

mkdir -p /tmp/crash/corefiles
chmod 775 /tmp/crash/corefiles
echo "/tmp/crash/corefiles/%e.%s.core" > /proc/sys/kernel/core_pattern

Where variables are:

%e is the filename
%g is the gid the process was running under
%p is the pid of the process
%s is the signal that caused the dump
%t is the time the dump occurred
%u is the uid the process was running under

Also, you have to set the core file size, below command sets the core file size to unlimited

ulimit -c unlimited

Now to check the core file size set for each thread within a process we can check using

cat /proc/<PID>/limits

The output of above command:

Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        unlimited            unlimited            bytes     
Max open files            10000                10000                files     
Max address space         unlimited            unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             31868                31868                processes 
Max locked memory         65536                65536                bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       31868                31868                signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us

As we can see from the above output max core file size is set to unlimited.

For more info please visit this link.
Linux Applications Debugging Techniques/Core files

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0