Файл дампа не создается

этой ссылке содержит хороший контрольный список, почему основные дампы не генерируются:

• ядро было бы больше, чем нынешний лимит.
• у вас нет необходимых разрешений для дампа ядра (каталога и файла). Обратите внимание, что основные дампы помещаются в текущий каталог процесса сброса, который может отличаться от родительского процесса.
• убедитесь, что файловая система доступна для записи и иметь достаточно свободного пространство.
• если подкаталог с именем core существует в рабочем каталоге, ядро не будет сброшено.
• если файл с именем core уже существует, но имеет несколько жестких ссылок, ядро не будет сбрасывать ядро.
• Проверьте разрешения на исполняемый файл, если исполняемый файл имеет SUID или sgid бит включен дампы памяти по умолчанию будет отключена. То же самое произойдет, если у вас есть разрешения на выполнение, но нет разрешений на чтение файла.
• убедитесь, что процесс не изменил рабочий каталог, ограничение размера ядра или флаг dumpable.
• некоторые версии ядра не могут сбрасывать процессы с общим адресным пространством (aka threads). Более новые версии ядра могут сбрасывать такие процессы, но будут добавлять pid к имени файла.
• исполняемый файл может быть в нестандартном формате не поддерживает дампы. Каждый исполняемый формат должен реализовывать процедуру дампа ядра.
• ошибка сегментации на самом деле может быть ядром Oops, проверьте системные журналы для любых сообщений Oops.
• приложение exit() вместо использования обработчика дампа ядра.

проверка:

$ sysctl kernel.core_pattern

чтобы увидеть, как создаются ваши дампы (%e будет именем процесса, а %t-системным временем).

если у вас Ubuntu, ваши дампы создаются apport на /var/crash, но в другом формате (отредактируйте файл, чтобы увидеть его).

вы можете проверить это:

sleep 10 &
killall -SIGSEGV sleep

если сброс ядра успешен, вы увидите "(Сброс ядра)" после индикации ошибки сегментации.

подробнее:

как для создания файла дампа ядра в Ubuntu

Ubuntu

пожалуйста, прочитайте больше по адресу:

https://wiki.ubuntu.com/Apport

помните, если вы начинаете сервер из сервиса, он начнет другой сеанс bash, поэтому ulimit не будет эффективным. Попробуйте поместить это в скрипт:

ulimit -c unlimited

для записи, на Debian 9 Stretch (systemd), Мне пришлось установить пакет systemd-coredump. После этого в папке /var/lib/systemd/coredump.

кроме того, эти coredumps сжимаются в . Для распаковки можно использовать пакет liblz4-tool такой: lz4 -d FILE.

чтобы иметь возможность отлаживать распакованный coredump с помощью gdb, мне также пришлось переименовать совершенно длинное имя файла во что-то более короткое...

кроме того, убедитесь, что у вас достаточно места на /var/core или там, где ваши основные дампы записываются. Если раздел заполнен почти полностью или при использовании диска 100%, это будет проблемой. Мои основные дампы в среднем несколько концертов, поэтому вы должны быть уверены, что на разделе доступно хотя бы 5-10.

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

Если ваш основной файл не создается по какой-либо причине, я рекомендую посмотреть на /var/log/messages. Там может быть подсказка, почему основной файл не создается. В моем случае была строка, указывающая первопричину:

Executable '/path/to/executable' doesn't belong to any package

чтобы обойти эта проблема edit /etc/abrt/abrt-action-save-package-data.conf и изменение ProcessUnpackaged от " Нет " До "да".

ProcessUnpackaged = yes

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

если он находится в дистрибутиве Linux (например, CentOS, Debian), то, возможно, самый доступный способ узнать о основных файлах и связанных с ними условиях находится на странице man. Просто запустите следующую команду с терминала:

man 5 core

хотя это не будет проблемой для человека, который задал вопрос, потому что они запустили программу, которая должна была создать основной файл в скрипте с командой ulimit, я хотел бы документировать, что команда ulimit специфична для оболочки, в которой Вы ее запускаете (например, переменные среды). Я потратил слишком много времени на запуск ulimit и sysctl и прочее в одной оболочке, а также команду, которую я хотел сбросить core в другой оболочке, и задавался вопросом, почему файл core не был произведенный.

Я добавлю его в свой bashrc. Sysctl работает для всех процессов после его выпуска, но ulimit работает только для оболочки, в которой он выпущен (возможно, также и для потомков), но не для других оболочек, которые случайно работают.

Примечание: Если вы сами написали какой-либо обработчик сбоев, ядро может не сгенерироваться. Так что ищите код в строку:

signal(SIGSEGV, <handler> );

таким образом, SIGSEGV будет обрабатываться обработчиком, и вы не получите дамп ядра.

Если вы называете daemon () и затем демонизировать процесс, по умолчанию текущий рабочий каталог изменится на /. Поэтому, если ваша программа является демоном, вы должны искать ядро в / каталог, а не в каталоге бинарных.

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