Create process dump linux

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) for further processing. A core dump is not typically used by an average user, but may be passed on to developers upon request where it can be invaluable 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.

Contents

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[1]:

To apply the setting immediately, use sysctl :

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[2][3]:

Then reload systemd’s configuration.

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.

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. [4]

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:

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:

Attach to the process:

Then at the (gdb) prompt:

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.

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:

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

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

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

Источник

Linux: создание coredump памяти процесса, systemd-coredump и Debian

Возникла необходимость получить дамп РНР-процесса на Debian 9.

Рассмотрим механизм ядра, позволящий создать дамп, и настройку создания дампов в Linux.

Ниже будем говорить о создании дампа памяти процесса в Linux, а не дампа ядра при kernel panic — там он иной, см. Kdump на Arch Wiki.

Linux Core Dump

Ядро создаёт дамп памяти процесса, если он выполнил недопустимую операцию, и должен быть остановлен.

Для этого при выполнении такой операции ядро отправляет один из аварийных сигналов процессу, после чего процесс обрабатывает сигнал сам, или с помощью сторонних обработчиков, что запускает механизм ядра, который создаёт дамп.

Список таких сигналов задаётся в макросе SIG_KERNEL_COREDUMP_MASK :

Который используется в другом макросе — sig_kernel_coredump :

Который срабывает в случае Fatal-ошибок, и вызывает do_coredump() :

Ну а сама do_coredump() создаёт дамп.

Сигналы и создание дампа

Проверим работу дампа.

Берём простой код на Си:

Собираем, и запускаем:

Во второй консоли — отправляем один из сигналов, например SIGSEGV (Segmentation violation), код 11:

В окне с приложением проверяем:

Проверяем файл дампа:

Аналогично можно создать дамп практически любого процесса, например — запустим sleep :

GDB — создать core dump

Кроме отправки сигнала — с помощью gdb , а именно gcore , можно создать дамп работающего процесса:

GDB — прочитать core dump

Что бы просмотреть содержимое — можем использовать gdb , которому передаём путь к исполняемому файлу, процесс которого сгенерировал дамп, и путь к самому файлу дампа:

kernel.core_pattern

Во время создания дампа — ядро проверяет параметр kernel.core_pattern , который определяет то, как будет обработан дамп.

Тут можно задать путь и имя файла, в который будет записан дамп, либо передать создание дампа внешнему обработчику, например systemd-coredump (рассмотрим ниже).

См. документацию Naming of core dump files тут>>>.

Из наиболее используемых опций тут:

• %e executable filename (without path prefix)
• %p PID of dumped process, as seen in the PID namespace in which the process resides
• %t time of dump, expressed as seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC)

Собственно файл /tmp/coredump-make_dump.2714790, который мы открыли в GDB, и состоит из kernel.core_pattern = /tmp/coredump-%e.%p :

1. /tmp каталог
2. %e — имя файла начинается с coredump + имя исполняемого файла make_dump
3. %p — и PID убитого процесса — 2714790

Помимо указания на путь к файлу и созданию его имени — в core_pattern можно указать пайп | , и передать данные через него, например в /dev/null или в хендлер типа systemd-coredump .

limits.conf

Кроме имени файла — ядро проверит значение soft и hard лимитов для core в /etc/security/limits.conf :

Либо проверяем в рабочем окружении:

Лимиты конкретного процесса можно получить через его дескриптор в /proc :

fs.suid_dumpable

Иногда дамп может не создаваться, если процесс в процессе выполнения выполнил запрос на смену UID, например через вызов setuid() .

Определяется флагом fs.suid_dumpable :

Может принимать значение 0, 1 или 2, см. man proc:

• 0: (default) This provides the traditional (pre-Linux 2.6.13) behaviour. A core dump will NOT be produced for a process which has changed credentials (by calling seteuid or similar) or whose binary does not have read permission enabled.
• 1: («debug«) All processes dump core when possible.
• 2: («suidsafe«) Any binary which normally would not be dumped (see «0» above) is dumped readable by root only.

systemd-coredump

В systemd , разумеется, добавлен свой обработчик дампов — уже упомянутый systemd-coredump .

На Arch Linux он используется по-умолчанию, на Debian 9 ставим из репозитория:

Файл параметров — /etc/systemd/coredump.conf .

После установки настраиваем ядро — через пайп передаём создание дампа в systemd-coredump :

Создаём дамп какого-то процесса:

coredumpctl

Для работы с дампами через systemd-coredump — используем coredumpctl :

В колонке SIG сразу видим код сигнала, с которым был убит процесс, в данном случае 11 == SIGSEGV .

Сами файлы дампов systemd-coredump сохраняет в /var/lib/systemd/coredump :

Просмотреть дамп — передаём условие для MATCH, например — PID:

Источник

How to generate a core dump in Linux on a segmentation fault?

I have a process in Linux that’s getting a segmentation fault. How can I tell it to generate a core dump when it fails?

12 Answers 12

This depends on what shell you are using. If you are using bash, then the ulimit command controls several settings relating to program execution, such as whether you should dump core. If you type

then that will tell bash that its programs can dump cores of any size. You can specify a size such as 52M instead of unlimited if you want, but in practice this shouldn’t be necessary since the size of core files will probably never be an issue for you.

In tcsh, you’d type

As explained above the real question being asked here is how to enable core dumps on a system where they are not enabled. That question is answered here.

If you’ve come here hoping to learn how to generate a core dump for a hung process, the answer is

if gcore is not available on your system then

Don’t use kill -SEGV as that will often invoke a signal handler making it harder to diagnose the stuck process

To check where the core dumps are generated, run:

where %e is the process name and %t the system time. You can change it in /etc/sysctl.conf and reloading by sysctl -p .

If the core files are not generated (test it by: sleep 10 & and killall -SIGSEGV sleep ), check the limits by: ulimit -a .

If your core file size is limited, run:

to make it unlimited.

Then test again, if the core dumping is successful, you will see “(core dumped)” after the segmentation fault indication as below:

Segmentation fault: 11 (core dumped)

Ubuntu

In Ubuntu the core dumps are handled by Apport and can be located in /var/crash/ . However, it is disabled by default in stable releases.

macOS

What I did at the end was attach gdb to the process before it crashed, and then when it got the segfault I executed the generate-core-file command. That forced generation of a core dump.

is the pid number of the process you want to attach.

Maybe you could do it this way, this program is a demonstration of how to trap a segmentation fault and shells out to a debugger (this is the original code used under AIX ) and prints the stack trace up to the point of a segmentation fault. You will need to change the sprintf variable to use gdb in the case of Linux.

You may have to additionally add a parameter to get gdb to dump the core as shown here in this blog here.

There are more things that may influence the generation of a core dump. I encountered these:

• the directory for the dump must be writable. By default this is the current directory of the process, but that may be changed by setting /proc/sys/kernel/core_pattern .
• in some conditions, the kernel value in /proc/sys/fs/suid_dumpable may prevent the core to be generated.

There are more situations which may prevent the generation that are described in the man page — try man core .

In order to activate the core dump do the following:

In /etc/profile comment the line:

In /etc/security/limits.conf comment out the line:

execute the cmd limit coredumpsize unlimited and check it with cmd limit :

to check if the corefile gets written you can kill the relating process with cmd kill -s SEGV

(should not be needed, just in case no core file gets written this can be used as a check):

Once the corefile has been written make sure to deactivate the coredump settings again in the relating files (1./2./3.) !

For Ubuntu 14.04

Check core dump enabled:

One of the lines should be :

/.bashrc and add ulimit -c unlimited to end of file and save, re-run terminal.

Build your application with debug information :

In Makefile -O0 -g

Run application that create core dump (core dump file with name ‘core’ should be created near application_name file):

/.bashrc require terminal restrart to changes make effect.

By default you will get a core file. Check to see that the current directory of the process is writable, or no core file will be created.

/abc> /usr/bin/cat def if cat crashes, is the current directory in question

/abc. Hmm, comments have to be 15 characters long!

It’s worth mentioning that if you have a systemd set up, then things are a little bit different. The set up typically would have the core files be piped, by means of core_pattern sysctl value, through systemd-coredump(8) . The core file size rlimit would typically be configured as «unlimited» already.

It is then possible to retrieve the core dumps using coredumpctl(1) .

The storage of core dumps, etc. is configured by coredump.conf(5) . There are examples of how to get the core files in the coredumpctl man page, but in short, it would look like this:

Find the core file:

Get the core file:

Ubuntu 19.04

All other answers themselves didn’t help me. But the following sum up did the job

/.config/apport/settings with the following content:

(This tells apport to also write core dumps for custom apps)

check: ulimit -c . If it outputs 0, fix it with

Just for in case restart apport:

Crash files are now written in /var/crash/ . But you cannot use them with gdb. To use them with gdb, use

• Some answers suggest changing core_pattern . Be aware, that that file might get overwritten by the apport service on restarting.
• Simply stopping apport did not do the job
• The ulimit -c value might get changed automatically while you’re trying other answers of the web. Be sure to check it regularly during setting up your core dump creation.

Источник

Linux: processes core dumps, systemd-coredump and Debian

Need to get a dump from fro ma PHP process on Debian 9.

In this post will take a Linux kernel mechanism to create and manage processes dumps.

Kernel’s dumps are created in another way, check Kdump на Arch Wiki.

Linux Core Dump

The kernel will create a process dump if it performed an invalid operation and has to be stopped.

To do so, the kernel will send a special signal to such a process so the process can handle it itself or using standard mechanisms and will cause the kernel to apply the mechanism to create a dump of the memory of this process.

The complete list can be found in the kernel source in the SIG_KERNEL_COREDUMP_MASK macros:

Which is used by the sig_kernel_coredump macros :

Which is called in case of Fatal-errors and in its turn will call the do_coredump() function:

And do_coredump() will create a memory dump and will save it on a hard disk.

Signals and dump creation

Let’s check how it’s working.

Take a simple code in C:

In another terminal – send a signal, for example SIGSEGV (Segmentation violation), code 11:

In a terminal with the app running check its output:

Check a dump file:

In the same way, you can create a dump for any already running process, for instances – run sleep :

GDB – create a core dump

Besides of a signal sending you can use gcore from the gdb :

GDB – read a core dump

To check a dump’s content you can use gdb and pass an executable as a first argument and a path to a dump file as a second argument:

kernel.core_pattern

During dump creation kernel will check the kernel.core_pattern parameter which determines how the dump will be handled.

Here you can specify a path and a filename with specificators or pass it external dumps handlers like systemd-coredump (рассмотрим ниже).

Check the Naming of core dump files documentation here>>>.

Most used options here are:

• %e executable filename (without path prefix)
• %p PID of dumped process, as seen in the PID namespace in which the process resides
• %t time of dump, expressed as seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC)

Our file /tmp/coredump-make_dump.2714790, which we observed in the GDB above consists of the kernel.core_pattern = /tmp/coredump-%e.%p :

1. /tmp catalog
2. %e – file name started with the coredump + an executable name файла make_dump
3. %p – and a killed process PID – 2714790

Also, instead of using the direct path and file name you can pass dump data via a pipe | to the /dev/null or to a handler like systemd-coredump .

limits.conf

Before creating a dump the kernel also will check soft and hard limits for the core in the /etc/security/limits.conf :

Or check directly in your current environment:

A running process limits can be found in its limits from the /proc :

fs.suid_dumpable

Sometimes a dump can be not created if a process made a suid-operation for example by using the setuid() syscall.

In this case, the behavior is controlled by the fs.suid_dumpable :

It can accept 0, 1 or 2, see the man proc:

• 0: (default) This provides the traditional (pre-Linux 2.6.13) behaviour. A core dump will NOT be produced for a process which has changed credentials (by calling seteuid or similar) or whose binary does not have read permission enabled.
• 1: (“debug“) All processes dump core when possible.
• 2: (“suidsafe“) Any binary which normally would not be dumped (see “0” above) is dumped readable by root only.

systemd-coredump

The systemd of course, has its own dumps handler – already mentioned systemd-coredump .

On Arch Linux is used by default, for Debian 9 can be installed with apt :

Config file – /etc/systemd/coredump.conf .

After installation configure the kernel – send dumps via a pipe to the systemd-coredump :

Create some dump:

coredumpctl

To work with dumps managed with systemd-coredump the coredumpctl utility can be used:

In the SIG column, we can see a signal sent to the process killed, in those cases it were 11 == SIGSEGV .

Dump files are located at the /var/lib/systemd/coredump directory:

To observe a dump’s content use info with some MATCH condition, for example, a PID:

Источник