php fpm core dump

Generate PHP core dumps on segfaults in PHP-FPM

Mattias Geniar, December 10, 2014

Follow me on Twitter as @mattiasgeniar

The PHP documentation is pretty clear on how to get a backtrace in PHP, but some of the explanations are confusing and seem focused on mod_php, instead of PHP-FPM. So here’s the steps you can take to enable core dumps in PHP-FPM pools.

Enable core dumps on Linux

Chances are, your current Linux config doesn’t support core dumps yet. You can enable them and set the location where the kernel will dump the core files.

You can use many different kinds of core dump variables for the filename, such as;

Now that your kernel knows where to save the core dumps, it’s time to change PHP-FPM.

Enable PHP-FPM core dumps per pool

To enable a core dump on a SIGSEGV, you can enable the rlimit_core option per PHP-FPM pool. Open your pool configuration and add the following.

Restart your PHP-FPM daemon ( service php-fpm restart ) to activate the config. Next time a SIGSEGV happens, your PHP-FPM logs will show you some more information.

You can find the core-dump in /tmp/coredump*.

The filename shows the program (php-fpm) and the PID (2393).

Reading the core dumps

This is one part that the PHP docs are pretty clear about, so just a copy paste with modified/updated paths.

There are other good-to-know gdb commands too, for instance – from your gdb shell (which you started above), type the following:

Not all data is always available, but it can help narrow down your search.

You can dive even further into each line of the stacktrace. The number in front of each line is a frame number. You can access them like this. In this example, I’ll explore frame 11.

First, check which data type they are.

This tells us that ‘i’ is an unsigned integer and that ‘execute_data’ is a struct. To see the value of each variables, print them.

These commands get you a long way: you can investigate each frame, show the arguments and local values, and inspect the value of each variable.

It’s time consuming tedious work, but it can get you to the fix.

Источник

Выполняю установку, настройку, сопровождение серверов. Для уточнения деталей используйте форму обратной связи

При падении приложения оно создаёт core-файл, который можно проанализировать. За создание core файлов отвечает утилита coreadm. С её помощью можно указать, где будут лежать core-файлы, для каких типов создавать core-файлы и т.д.

Важно понимать, что core dump файлы системы и процессов отличаются, и их нужно анализировать по разному.

coreadm

Данная команда введённая без параметров выведет текущие настройки:

Для того, что бы начать использовать coreadm установим путь, где будут храниться наши core-файлы:

Далее выберем то, что хотим что бы попадало в core-файл:

Возможные значения для content (оставлю без перевода, что бы не терялся смысл):

— ctf: CTF type information sections for loaded object files
— data: Writable private file mappings — dism: DISM mappings
— heap: Process heap
— ism: ISM mappings
— rodata: Read-only private file mappings
— shanon: Anonymous shared mappings
— shfile: Shared mappings that are backed by files
— shm: System V shared memory
— stack: Process stack
— symtab: Symbol table sections for loaded object files
— text: Readable and executable private file mappings

Либо просто указать all что бы попадало всё.
Есть ещё опции -e/-d которые означают включить/выключить определённые параметры.
Напомню, что coreadm управляется через SMF сервис svc:/system/coreadm:default. Так же можно отметить, что все изменения сохраняются в файле /etc/coreadm.conf

Правда частенько системные администраторы отключают создание core-файлов для процессов

так как они могут генерить большие объёмы данных.

При отлавливании багов лучше всего включать создание всех

Отдельно хочется отметить команду

которая позволит регистрировать в логах появление core-файлов

dumpadm

Данная команда управляет параметрами системного crash dump’a. Управляется она тоже через SMF — svc:/system/dumpadm:default и работает через устройство /dev/dump. Команда без параметров выведет текущие настройки:

savecore/gcore

Эта утилита служит для сохранения core dump файлов. Ею очень удобно сбрасывать в дамп текущее состояние системы:

Для того, чтобы проанализировать дамп, можно восстановить его в привычном виде:

Анализ core dump-файлов.

Для анализа можно использовать отладчик mdb. Вот небольшой пример использования

Очень хорошо анализ core dump файлов описаны здесь

http://solaristhings.blogspot.com/2006/08/dont-be-afraid-of-mdb.html
http://kristof.willen.be/node/1100
http://www.c0t0d0s0.org/archives/4391-Less-known-Solaris-Features-About-crashes-and-cores.html
http://www.cuddletech.com/blog/pivot/entry.php?id=965
http://www.cuddletech.com/blog/pivot/entry.php?id=966
http://eteck.blogspot.com/2012/04/solaris-crash-dump-anylysis.html

Анализ core файлов.

Небольшой пример анализа core файла:

Очень удобно анализировать через gdb, но он не входит в базовую систему и его придётся доставлять отдельно.

Очень удобно так же запустить программу через gdb:

Источник

Arch Linux

You are not logged in.

#1 2015-03-06 11:35:35

php-fpm and core dumps

I’m using php-fpm 5.6.6-1 with Apache 2.4.12-2 (I followed installation instruction here: https://wiki.archlinux.org/index.php/Ap … proxy_fcgi).

Enabled modules in httpd.conf:

Php-fpm seems to segfault a lot, and it is flooding the /var/lib/systemd/coredumps/ folder with a lot of core dumps, although I have set rlimit_core to something sensible in /etc/php/php-fpm.conf.

I try to follow the steps described here: https://rtcamp.com/tutorials/php/core-dump-php5-fpm/ but all the above core dumps can’t be read (one example: core.php-fpm.1000.446d4ac5303e4dfabd5051b441af66c1.5228.1425640939000000.lz4).

Appreciate any insight.

Last edited by ewaller (2015-03-07 01:30:35)

#2 2015-03-07 01:35:18

Re: php-fpm and core dumps

First, Welcome to Arch Linux
Second, Thank you for using BBCode tags
Third, I hope you don’t mind that I exercised my powers and changed your quote tags to code tags.

What do you mean the core dumps cannot be read? What are the error messages? Is the user you are using to try to read those core dumps in the correct groups (httpd) to be allowed to read them? Is there anything interesting in the journal that coincides with the segfaults?

Источник

Куда записываются Core dump-ы?

программа при старте выдала сообщение:

Мои вопросы:
1) кто записывает core-dump-ы? Какой-то модуль ядра? Какой?
man systemd-coredump
2) куда записываются core-dump-ы? (в какую директорию)

я не умею пользоваться gdb, что делать дальше?

Погоди, а зачем тебе кордамп тогда?

ну я думал, что мне посоветуют какую-нибудь огромную IDE, я её запущу и мне всё объяснят, что произошло и из-за чего возникла ошибка.

Переходи на Java, там всё как ты хочешь.

Ну, нет. Программа, к тому же, должна была бы быть скомпилена с дебаг-символами, а у тебя, похоже, не этот случай.

и файл у меня не обрезаный:

я не умею пользоваться gdb, что делать дальше?

Учиться пользоваться gdb.

Ну уж нет! И вообще, я же тебя неоднократно просил в мои треды не отвечать. Тут даже тегов твоих любимых нет.

Да ещё и ассемблер… Непонятен use case, в общем.

Это нормально. Каждый раз когда я пишу на LOR, вам всегда ничего непонятно, всегда вы хотите в чужой карман залезть.

Но там на английском, а его ТС наотрез отказывается учить.

Гугл буквально первым результатом выдаёт

Источник

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 — прочитать core dump

kernel.core_pattern

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

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

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

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

limits.conf

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

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

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

fs.suid_dumpable

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

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

systemd-coredump

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

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

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

coredumpctl

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

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

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

Источник