Here's how to enable core dump files to write for analysis on application crashes:

# cat  /etc/sysctl.conf|grep core
# Controls whether core dumps will append the PID to the core filename.
kernel.core_uses_pid = 1
#

Core patterns, if you want to write to directories other then where the process is currently running from (which could be anywhere) can be specified in this manner on the fly:

# cat /proc/sys/kernel/core_pattern
core
# echo "/cores/core-%e-%p-%h-%t" > /proc/sys/kernel/core_pattern
# cat /proc/sys/kernel/core_pattern
/cores/core-%e-%p-%t
#

Optionally, configure it permanently in:

# vi /etc/sysctl.conf

and set:

kernel.core_pattern=/cores/core.%e.%p.%h.%t

The documented patterns can be found at the kernel.org site:

core_pattern:

core_pattern is used to specify a core dumpfile pattern name.
. max length 128 characters; default value is "core"
. core_pattern is used as a pattern template for the output filename;
  certain string patterns (beginning with '%') are substituted with
  their actual values.
. backward compatibility with core_uses_pid:
	If core_pattern does not include "%p" (default does not)
	and core_uses_pid is set, then .PID will be appended to
	the filename.
. corename format specifiers:
	%<NUL>	'%' is dropped
	%%	output one '%'
	%p	pid
	%u	uid
	%g	gid
	%s	signal number
	%t	UNIX time of dump
	%h	hostname
	%e	executable filename (may be shortened)
	%E	executable path
	%<OTHER> both are dropped
. If the first character of the pattern is a '|', the kernel will treat
  the rest of the pattern as a command to run.  The core dump will be
  written to the standard input of that program instead of to a file.

Check our core file limits:

# ulimit -c
unlimited
#

Ensure the default profile /etc/profile has lines similar too:

# cat /etc/profile
.
.
# Enable core files.
ulimit -S -c unlimited > /dev/null 2>&1
.
.
#

For RHEL 7 or CentOS 7 we set it this way alonside the ulimit -S -c unlimited command:

# grep DefaultLimitCORE /etc/systemd/system.conf
DefaultLimitCORE=infinity
#

 

then following up with a reboot of the host.

Next let's test it out, by killing your own shell session:

# kill -s SIGSEGV $$

Warning: Program '/bin/bash' crashed.

Then in a new window check that the core file was generated where it was expected:

# ls -al
total 1468
drwxr-xr-x    2 root root    4096 Oct 13 12:00 .
drwxrwxrwt. 171 root root   12288 Oct 13 11:27 ..
-rw——-    1 root root 1671168 Oct 13 12:00 core-bash-3891-1350144049
# pwd
/tmp/core
#

 

Now since we know why it crashed, a  tad bit of core analysis howto is in order to highlight what lead up to it:

# gdb bash-crash /cores/core-bash-3891-1350144049
GNU gdb (GDB) Fedora (7.1-28.fc13)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>…
bash-crash: No such file or directory.
Missing separate debuginfo for the main executable file
Try: yum –disablerepo='*' –enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/58/12a4e761c1a6c7622c6a105e0cc9150df6f415
[New Thread 3891]
Core was generated by `/bin/bash'.
Program terminated with signal 11, Segmentation fault.
#0  0x00650416 in __kernel_vsyscall ()
(gdb)

 

Enjoy!

Cheers,
TK