How to Set the Core Dump File Path

1. Overview

The Linux kernel generates a core dump file when a program unexpectedly crashes.

Setting the core dump file path is an important aspect of system administration. This is especially true when troubleshooting issues that may have led to program or system crashes.

Indeed, core dump files could contain sensitive data. Thus, while storing and gathering information for stability and troubleshooting, one should exercise care.

In this tutorial, we’ll understand the basics of core dumps and how they are generated. More specifically, we’ll see how to customize the location where these dumps are stored in Ubuntu.

2. What Is a Core Dump?

A core dump, also known as a core file, is a snapshot of the process memory when it crashes. It serves as a valuable diagnostic tool for understanding the cause of a program failure. For example, it can contain information that can be used for debugging a program.

Analyzing core dumps can help developers and system administrators identify the root causes of issues. This may further facilitate faster resolution.

However, for users not interested in debugging a program, such files can be deleted with the rm command:

$ rm <core_file>

Alternatively, we can just ignore the file, as a newer core file often automatically overwrites the old one.

3. Generating a Core Dump

Core dumps can be created intentionally or automatically when a program causes a critical error.

To intentionally force a core dump, developers often set specific instructions within the code. Also, users can employ tools like gcore for this purpose.

Technically, the kernel is responsible for initiating core dumps when a program unexpectedly ends. Further, dumps can be directed to another program, like systemd-coredump, for further processing.

To get the core dump file, we usually need to configure two prerequisites:

• ulimit set to unlimited
• disabling Apport on Ubuntu

Let’s do that for each one.

3.1. ulimit

The ulimit command controls system resource limits for a process initiated by a shell.

By default, a normal user can’t generate a core file since the max core file size is 0. We can confirm this via the -a option of ulimit:

$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals...

Thus, we use the ulimit command to set the core file size to unlimited:

$ ulimit -c unlimited

This enables the core file generation.

Further, we can edit the /etc/security/limits.conf file to set the limit of ulimit for all users.

3.2. Apport

Apport is a system error reporting service in Linux. It automatically collects crash information, which includes core dump files. Also, it attempts to report and analyze the crash issue.

By default, core dumps get redirected to Apport on Ubuntu. We can see this behavior in the /proc/sys/kernel/core_pattern file:

$ cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E

Thus, if we want manual control over the core dump, we may need to stop and disable the Apport service with the systemctl command:

$ sudo systemctl stop apport.service
$ sudo systemctl disable apport.service

Disabling Apport ensures that it doesn’t automatically handle core dumps. Importantly, this way, the service doesn’t overwrite the /proc/sys/kernel/core_pattern. Thus, users can manually inspect and analyze core dump files.

The file pattern inside the /proc/sys/kernel/core_pattern file should now only contain core:

$ cat /proc/sys/kernel/core_pattern
core

After meeting the prerequisites, let’s now see how we can generate a core dump.

3.3. Example Core Dump Generation

For generating a sample core dump file, we start a process using the sleep command and then abruptly terminate it using the kill command:

$ sleep 100 &
$ kill -s SIGTRAP $(pgrep sleep)
Trace/breakpoint trap (core dumped)

Let’s break down the kill command used here:

• kill: sends a signal as specified with the -s option to a process
• SIGTRAP: a signal, prefixed by -s, used for debugging purposes
• $(pgrep sleep): returns the PID of any sleep process

After we’ve learned to generate core dump files, let’s see where they are in the system.

4. Default Location of the Core Dump

The core dump file defaults to the name core. Furthermore, this file resides within the working directory of the application.

For example, in the above case, we ran the sleep command inside the user’s home directory. Thus, the core file is now in the home directory of the user:

$ ls /home/vagrant
core

While this may be convenient for some scenarios, it might not be ideal for various reasons such as security or disk space considerations.

5. Setting the Location of the Core Dump

Let’s suppose we want to store core dumps in the directory /var/coredump/ and name them with the prefix core.

For this, we create the target directory /var/coredump:

$ sudo mkdir /var/coredump

Subsequently, we provide the read and write permissions to this directory:

$ sudo chmod a+rw /var/coredump

This ensures that the target directory provides appropriate permissions for the storage of core dump files.

Let’s now see how to set this new location as the target for core dump files.

5.1. Using /proc/sys/kernel/core_pattern

One way to set the location of core dumps is by configuring the /proc/sys/kernel/core_pattern file. This file sets the naming and placement of core dumps.

Let’s first see the contents of the file using the cat command:

$ cat /proc/sys/kernel/core_pattern
core

Now, we add the required entry to the /proc/sys/kernel/core_pattern file:

$ cat /proc/sys/kernel/core_pattern
/var/coredump/core_%e.%p_%t

Here, each parameter has a specific meaning:

• %e: represents the executable name
• %p: represents the process ID
• %t: adds a timestamp

Indeed, formatting in this way ensures a structured and organized approach to managing core dumps.

5.2. Using the sysctl Command

The sysctl command is another way to dynamically change kernel parameters, including the core dump location.

As a result, we can set the new core dump location result using sysctl:

$ sudo sysctl -w kernel.core_pattern="/var/coredump/core_%e.%p"

Either way, the changes get reset after each reboot.

5.3. Persist Core Dump Location Changes

Indeed, after testing, we can modify the sysctl.conf file to make the changes permanent. In this file, we set the kernel.core_pattern parameter to point to the new dump file:

$ cat /etc/sysctl.conf
kernel.core_pattern='/var/coredump/core_%e.%p_%t'

Now, let’s again create a core dump and see the location of the generated dump file:

$ sleep 100 &
$ kill -s SIGTRAP $(pgrep sleep)

Using the ls command, let’s check if the set location contains the core dump file:

$ ls -l /var/coredump
total 112
-rw------- 1 vagrant vagrant 3809 Dec 3 09:04 "core_sleep.14119_170159"

At this point, we successfully configured the location.

5.4. Verify Core Dump Location

Let’s again generate a core dump file using the sleep and kill commands:

$ sleep 500 &
$ kill -s SIGTRAP $(pgrep sleep)

To verify the new location, let’s see the content of the directory core_dumps:

$ ls -l /var/coredump
total 116
-rw------- 1 vagrant vagrant 3809 Dec  3 09:08 core_sleep.14134

Thus, the core dump files are now generated at the new location.

6. Conclusion

In this article, we talked about core dumps, what they are, and how they are generated.

In particular, we’ve seen different ways to modify the location of core dump files. First, we used the core_pattern file for setting the core dump file location. Then, we used the sysctl command to achieve the same goal. Finally, we ensured our settings remain after a system reboot.