Linux core dump enable

Enable and Analyse Core Dumps in Linux

To debug an executable one can run it under control of gdbserver/gdb. This also allows to debug issues with abnormal termination caused by receiving signals. See Hello World application on Embedded Linux for a possible setup. For cases which do not allow to run gdb core dumps can help in debugging issues with abnormal termination. The Linux kernel can write a file containing the state of a process when the process receives certain signals, e.g. segmentation fault or illegal instruction. Such files are called core dumps and contain a snapshot of the allocated memory and registers and can later be used with gdb to analyse the causes of the signal. See also ‘man core’.

Core Dumps on CPU Signals​

Preconditions​

Make sure the Linux kernel has the needed configuration options set as we don’t enable these by default. Check and if needed recompile the kernel with enabled core dump options. Check for 3.0, 3.1 kernels:

zcat /proc/config.gz | grep CONFIG_ELF_CORE 

zcat /proc/config.gz | grep CONFIG_COREDUMP 

Enabling Core Dumps​

The following enables core dump generation when a user process triggers a signal and sets the core file location to /tmp/ with a sensible name. Note that these settings aren’t stored persistently.

ulimit -c unlimited echo 1 > /proc/sys/kernel/core_uses_pid echo "/tmp/core-%e-%s-%u-%g-%p-%t" > /proc/sys/kernel/core_pattern 

echo 2 > /proc/sys/fs/suid_dumpable 

Depending on the memory usage of a process core files can be huge. Enabling core dumps on a system can fill up its mass storage over time. To enable core dumps on production systems it is highly recommended to use a daemon to manage the core dumps (e.g. make sure that the core dumps do not use more than a certain amount of space). Systemd might be a viable solution for this, however the coredump functionality is not enabled by default in OpenEmbedded (see recipes-core/systemd/systemd_xxx.bb in OpenEmbedded core).

Trigger a Core Dump​

To test the creation of core dumps, one can use the kill command to send a segmentation fault signal to the process:

Create a Core Dump of a Running Application​

To create a single core dump without provoking an abnormal process termination the utility gcore can be used. This allows to create a core dump at any time of execution. The utility gcore is part of gdb, one can install it using the package feeds:

# gcore -o /tmp/core-myapp 280 0x76f46588 in read () from /lib/libc.so.6 Saved corefile /tmp/core-myapp.280 

Analysing Core Dumps​

A cross gdb can be used to analyse a core file. Additionally to the core dump gdb needs the executable and all linked static object files. One can use the OpenEmbedded built cross gdb and the target sysroot for that. Copy the core file to your development PC into the OpenEmbedded sysroot and use gdb to do the analysis: In oe-core/build/out-glibc/sysroot/colibri-t30:

../x86_64-linux/usr/bin/armv7ahf-vfp-neon-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi-gdb -ex 'set sysroot .' -ex 'core-file ./core-firefox-4-0-0-596-1402701200' usr/lib/firefox/firefox 

Источник

Core dump

A core dump is a file containing a process’s address space (memory) when the process terminates unexpectedly. Core dumps may be produced on-demand (such as by a debugger), or automatically upon termination. Core dumps are triggered by the kernel in response to program crashes, and may be passed to a helper program (such as systemd-coredump(8) ) for further processing. A core dump is not typically used by an average user, but developers could use it as a post-mortem snapshot of the program’s state at the time of the crash, especially if the fault is hard to reliably reproduce.

Warning: Core dumps should be shared only with trusted parties as they may contain sensitive data (such as passwords or cryptographic keys).

Disabling automatic core dumps

Users may wish to disable automatic core dumps for a number of reasons:

• Performance: generating core dumps for memory-heavy processes can waste system resources and delay the cleanup of memory.
• Disk space: core dumps of memory-heavy processes may consume disk space equal to, if not greater, than the process’s memory footprint if not compressed.
• Security: core dumps, although typically readable only by root, may contain sensitive data (such as passwords or cryptographic keys), which are written to disk following a crash.

Using sysctl

sysctl can be used to set the kernel.core_pattern to nothing to disable core dump handling. Create this file

kernel.core_pattern=/dev/null

To apply the setting immediately, use sysctl :

# sysctl -p /etc/sysctl.d/50-coredump.conf

Using systemd

systemd’s default behavior is defined in /usr/lib/sysctl.d/50-coredump.conf , which sets kernel.core_pattern to call systemd-coredump . It generates core dumps for all processes in /var/lib/systemd/coredump . systemd-coredump behavior can be overridden by creating a configuration snippet in the /etc/systemd/coredump.conf.d/ directory with the following content (See coredump.conf(5) § DESCRIPTION , [1]):

/etc/systemd/coredump.conf.d/custom.conf

Note: Do not forget to include the [Coredump] section name, otherwise this option will be ignored: systemd-coredump[1728]: [/etc/systemd/coredump.conf.d/custom.conf:1] Assignment outside of section. Ignoring.

Then reload the systemd manager configuration with daemon-reload.

This method alone is usually sufficient to disable userspace core dumps, so long as no other programs enable automatic core dumps on the system, but the coredump is still generated in memory and systemd-coredump run.

If you want to completely disable all coredump handling except for a log entry, set the ProcessSizeMax=0 option. See systemd-coredump(8) § Disabling coredump processing .

Using PAM limits

The maximum core dump size for users logged in via PAM is enforced by limits.conf. Setting it to zero disables core dumps entirely. [2]

Using ulimit

Command-line shells such as bash or zsh provide a builtin ulimit command which can be used to report or set resource limits of the shell and the processes started by the shell. See bash(1) § SHELL BUILTIN COMMANDS or zshbuiltins(1) for details.

To disable core dumps in the current shell:

If the system is setup to pipe coredumps into a program such as systemd-coredump using kernel.core_pattern , Linux ignores the ulimit setting and only the dumpable prctl(2) can be used to disable coredump processing for selected processes.

Making a core dump

To generate a core dump of an arbitrary process, first install the gdb package. Then find the PID of the running process, for example with pgrep:

(gdb) generate-core-file Saved corefile core.2071 (gdb) quit

Now you have a coredump file called core.2071 .

Where do they go?

The kernel.core_pattern sysctl decides where automatic core dumps go. By default, core dumps are sent to systemd-coredump which can be configured in /etc/systemd/coredump.conf . By default, all core dumps are stored in /var/lib/systemd/coredump (due to Storage=external ) and they are compressed with zstd (due to Compress=yes ). Additionally, various size limits for the storage can be configured.

Note: The default value for kernel.core_pattern is set in /usr/lib/sysctl.d/50-coredump.conf . This file may be masked or overridden to use a different setting following normal sysctl.d(5) rules.

To retrieve a core dump from the journal, see coredumpctl(1) .

Examining a core dump

Use coredumpctl to find the corresponding dump:

You need to uniquely identify the relevant dump. This is possible by specifying a PID , name of the executable, path to the executable or a journalctl predicate (see coredumpctl(1) and journalctl(1) for details). To see details of the core dumps:

# coredumpctl info match 

Pay attention to «Signal» row, that helps to identify crash cause. For deeper analysis you can examine the backtrace using gdb:

# coredumpctl gdb match 

When gdb is started, use the bt command to print the backtrace:

See Debugging/Getting traces if debugging symbols are requested, but not found.

Cleanup of core dump files

The core dump files stored in /var/lib/systemd/coredump/ will be automatically cleaned by systemd-tmpfiles —clean , which is triggered daily with systemd-tmpfiles-clean.timer . Core dumps are configured to persist for at least 3 days, see systemd-tmpfiles —cat-config .

See also

• american fuzzy lop — A tool for automated tests of the kernel and programs
• Filesystem fuzzing — LWN article about testing filesystems for bugs

Источник

How to Enable Core Dump in Linux

This tutorial explains how to enable core dump in Linux.

After reading this tutorial you will be able to check if core dump is enabled, how to enable or disable it, how to view, and more.

Core dump files are used to diagnose and debug software crashes.

A core dump is a non-structured registry of the memory content containing information on the execution of software abnormally terminated, including the reason for the crash.

In other words, this is a snapshot of the program state with the execution and termination process recorded. You can think about core dump as an airplane black box or a logs file.

Core dump management may vary from a Linux distribution to other, this tutorial is optimized both for Debian based Linux distributions like Ubuntu, and RedHat Linux distributions like CentOS.

All instructions included in this article contain screenshots, making it easy for every Linux user to understand and follow them.

Enabling Core Dump in Linux

The first step is to check if core dump is enabled. For this purpose, use the following command. If the core file size is 0, as in the example below, then core dump is disabled.

To enable core dump in Linux, with unlimited size, use the following command. Then, execute the previous command you will see the 0 is replaced with unlimited.

To enable core dump permanently, you need to edit the file /etc/security/limits.conf. Open it with privileges using any text editor.

Then, add the following line and close saving changes:

Now, let’s try to execute an application programmed to crash intentionally.

As you can see in the screenshot below, the core dump was generated.

According to the default configuration on Debian based Linux distributions, the core dump should be created in the current directory. You can check this by executing the following command:

As you can see in the previous figure, the core dump was properly generated.

To view it, you need to install the GNU Debugger. You can install it using apt as shown in the image below.

Note that RedHat based systems users must use Automatic Bug Reporting Tool (ABRT) instead of GDB.

To view the core dump files, use the following syntax:

You will be asked to press “c” to continue. Press it and you will see the report.

By default, core dump files are called core.

You can change the name and destination patterns to identify core dumps easily.

The command is the following:

-%u will include the User ID in the core dump name. The -%g will include the Group ID and %p the PID.

As you can see, after executing the crashing app again, a new core dump is generated including UID, GID and PID.

There are additional values you can use to define core dump patterns. You can find them in the list below.

VALUE	Function
%	‘%’ is dropped
%%	output one ‘%’
%p	Includes PID
%P	Includes Global PID
%i	Shows Thread ID
%I	Global Thread ID
%u	User ID
%g	Group ID
%d	Dump mode
%s	Signal number
%t	UNIX time of dump
%h	Hostname
%e	Executable file
%E	Executable file path

You also can define a core dumps directory to store them.

The syntax is the following:

“/cored” is the directory where core dumps will be stored. This names will include both PID and Global PID.

As you can see, after running the crashing app, the core dump was stored in the /cored directory including both PID and GPID.

How to Disable Core Dumps in Linux

Disabling core dump is so simple as enabling them.

Just set the limit to 0 by running the following command:

To permanently disable core dump, edit the /etc/security/limits.conf file using any text editor as shown in the figure below.

Add the following 2 lines, then exit saving changes.

Finally, check if core dump was successfully disabled by executing the following:

As you can see the core file size limit is 0, core dump is disabled.

Conclusion

Core dumps can be very helpful for debugging procedures and identifying failures. Becoming familiar to them is recommended to improve problems response. They also can be useful to capture data freed by dynamic memory, fetching information on no longer running programs. They also can be helpful for programmers to find errors. A core dump can save the state of a process at a defined state to return to it later. It can also be dumped onto a remote host over a network (which is a security risk).

About the author

David Adams

David Adams is a System Admin and writer that is focused on open source technologies, security software, and computer systems.

Источник