> For the complete documentation index, see [llms.txt](https://mariadb.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mariadb.com/docs/analytics/mariadb-columnstore/management/monitoring-and-logs/capturing-system-level-process-dumps-core-dumps.md).

# Capturing System-Level Process Dumps (Core Dumps)

When a critical MariaDB ColumnStore process (such as `PrimProc` or `ExeMgr`) terminates unexpectedly due to a segmentation fault (segfault), the operating system can write the contents of its memory state to a core dump file. These files are invaluable for post-mortem debugging and determining the exact root cause of a failure.

By default, many modern Linux distributions limit or disable core dump generation to conserve disk space. This guide outlines how to configure a RHEL/CentOS-based system to capture complete, uncompressed core dumps for ColumnStore processes.

{% stepper %}
{% step %}

### Configure OS Resource Limits (`limits.conf`)

The operating system enforces shell-level resource limits (`ulimits`) that prevent large processes from writing files that exceed set maximum sizes. Because ColumnStore processes utilize substantial memory, resource limits must be explicitly set to `unlimited`.

1. Open `/etc/security/limits.conf` in a text editor as `root`:

   ```bash
   sudo vi /etc/security/limits.conf
   ```
2. Append the following lines to ensure the `mysql` user accounts (and root if applicable) have unrestricted core dump size permissions:

   ```
   mysql      soft    core    unlimited
   mysql      hard    core    unlimited
   root       soft    core    unlimited
   root       hard    core    unlimited
   ```
3. Save and close the file.
   {% endstep %}

{% step %}

### Configure Systemd Coredump Behavior (`coredump.conf`)

On systemd-enabled operating systems (RHEL/CentOS 7/8/9), core dumps are often intercepted and managed by `systemd-coredump`. You must ensure that systemd does not truncate large core files.

1. Open `/etc/systemd/coredump.conf`:

   ```bash
   sudo vi /etc/systemd/coredump.conf
   ```
2. Modify or add parameters under the `[Coredump]` section to adjust max sizes for large analytics engine processes:

   ```ini
   [Coredump]
   Storage=external
   Compress=no
   ProcessSizeMax=unlimited
   ExternalSizeMax=unlimited
   MaxUse=20G
   ```
3. Reload the systemd daemon to apply changes:

   ```bash
   sudo systemctl daemon-reload
   ```

{% endstep %}

{% step %}

### Configure Core Storage Path (`sysctl.conf`)

To ensure core dumps are saved persistently and with standard naming conventions, the kernel must be directed to write files into a dedicated space using a custom file pattern.

1. Open `/etc/sysctl.conf` to persistently set kernel behavior:

   ```bash
   sudo vi /etc/sysctl.conf
   ```
2. Add the following line to route core dumps into a persistent directory layout using variables for process name (`%e`), process ID (`%p`), and epoch timestamp (`%t`):

   ```
   kernel.core_pattern = /var/crash/core-%e-%p-%t
   ```
3. Force the kernel to read and apply the parameters immediately without a reboot:

   Bash

   ```bash
   sudo sysctl -p
   ```

{% endstep %}

{% step %}

### Create and Secure the Target Directory

For a service process to successfully write a core file, it requires absolute write access to the targeted filesystem partition.

1. Create the targeted path directory specified in the kernel pattern:

   ```bash
   sudo mkdir -p /var/crash
   ```
2. Apply full read, write, and execute permissions globally (`777`). This is an explicit requirement to guarantee that the `mysql` runtime context can safely dump its memory segments into the root-owned path directory:

   ```bash
   sudo chmod 777 /var/crash
   ```

{% endstep %}

{% step %}

### Verification

To verify that changes have been applied correctly across the node, start a new interactive session or restart the core process and check that resource limits have refreshed:

```bash
ulimit -c
```

*Expected Output:*

```
unlimited
```

You can also view the limits of a currently running ColumnStore process by checking its runtime environment explicitly via its PID:

```bash
cat /proc/$(pidof PrimProc)/limits | grep "Max core file size"
```

{% endstep %}
{% endstepper %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://mariadb.com/docs/analytics/mariadb-columnstore/management/monitoring-and-logs/capturing-system-level-process-dumps-core-dumps.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.