- core_pattern obeys the current chroot, which effectively makes it useless as a way to collect cores centrally if your system has any chrooted processes.
- core_pattern explicitly prevents you from dumping to non-regular files. In a virtual environment it’d be very useful to coredump to a block device.
Tag Archives: coredump
Core dumps are one way to track down those segfaults which can’t easily be captured in gdb, either because they are rare and unpredictable, or they happen in some deeply nested subprocess. But no one likes core files being left all over the filesystem. Instead, capture your core dumps in a central directory and analyze them later at your pleasure.
Add this to
/etc/rc.local and also run it as a root:
mkdir -p /var/log/core chmod 0777 /var/log/core echo "/var/log/core/core.%t.%p.%e" > /proc/sys/kernel/core_pattern echo 0 > /proc/sys/kernel/core_uses_pid
(By the way, ABRT also uses core_pattern so running these commands will disable ABRT, if you care).
You may need to adjust
* hard core unlimited * soft core unlimited
On some versions of Fedora, also comment out this line from
/etc/profile. (What on earth was the thinking behind this?)
#ulimit -S -c 0 > /dev/null 2>&1
Check that core dumps are enabled. This is what you should see (you may need to log out and log in again):
$ ulimit -Hc unlimited $ ulimit -Sc unlimited
Now, any time a process crashes, it will leave a core file in
$ ls -l /var/log/core/ total 1800 -rw-------. 1 rjones rjones 303104 May 5 15:25 core.1273069556.28228.ls [...] $ gdb /bin/ls /var/log/core/core.1273069556.28228.ls [...]
This doesn’t enable core dumps for all services, since anything started at boot goes down a different path. If you restart individual services by hand, then core dumps will be enabled for those.