Ядро сброшено, но файл ядра не находится в текущем каталоге?

277

Во время работы программы на Си написано «(core dumped)», но я не вижу никаких файлов по текущему пути.

Я установил и проверил ulimit:

ulimit -c unlimited 
ulimit -a

Я также пытался найти файл с именем "core", но не получил файл дампа ядра?
Любая помощь, где мой основной файл?

c linux coredump

— webminal.org
источник

1

Программа вызывает chdir в какой-то момент? Если так, посмотрите там.

— Уильям Перселл

2

Программа меняет свой рабочий каталог? Смотреть там.

— Ричард Пеннингтон

Я искал бы весь жесткий диск для недавнего файла;)

— Хэмиш Грубиджан

1

ой нет, его там нет ... Я проверил это .. запрограммируйте chdir в / mnt и / я проверил обе директории, но не смог найти файл. Я даже нашел / -name "* core". даже это не показывало мне файл. Программа использует C + sqlite, при этом вставляя значения в дампы ядра. В первый раз говорится об ошибке подтверждения == 0, а во второй раз об ошибке = 101 ..

— webminal.org

8

Да, если вы переопределите /proc/sys/kernel/core_patternстроку, начинающуюся с /tmpтогда, то туда и пойдут дампы ядра.

— Эфимент

240

Прочитайте /usr/src/linux/Documentation/sysctl/kernel.txt .

[/ proc / sys / kernel /] core_pattern используется для указания имени шаблона файла дампа ядра.

Если первый символ шаблона - «|», ядро будет рассматривать оставшуюся часть шаблона как команду для запуска. Дамп ядра будет записан в стандартный ввод этой программы, а не в файл.

Вместо того, чтобы записывать дамп ядра на диск, ваша система настроена на отправку его abrtпрограмме. Automated Bug Reporting Tool , возможно, не так документально, как это должно быть ...

В любом случае, быстрый ответ заключается в том, что вы должны быть в состоянии найти ваш основной файл в том месте /var/cache/abrt, где abrtон хранится после вызова. Точно так же другие системы, использующие Apport, могут сжимать ядра /var/crashи так далее.

— ephemient
источник

30

да, я отредактировал core_pattern со следующим содержимым echo "core.% e.% p"> / proc / sys / kernel / core_pattern .. теперь он создает файл дампа ядра в текущем каталоге. с именем "core.giis.12344" и т. д. Спасибо всем за ваши ответы / комментарии / советы.

— webminal.org

20

Просто чтобы заметить, что в программе Fedora 18 abrt хранятся дампы ядра /var/spool/abrt/вместо/var/cache/abrt

— Нельсон

4

Есть ли способ разрешить пользователям настраивать это для себя, а не всем, кому приходится использовать конфигурацию системы?

— allyourcode

Когда эта команда запущена и процесс запущен, stdout и stderr не открываются по умолчанию? Я вижу, что происходят очень странные вещи. когда я использую dup2 из stderr и stdout в свой пользовательский файл (applog.txt), данные, которые я записываю в другой файл (mycore.BIN), перенаправляются в файл, который я использовал для перехвата stdout & stderr (applog.txt) , Есть ли хорошее чтение об этом? Пожалуйста, предложите. Спасибо

— мк ..

20

systemd в магазине archlinux coredumps in/var/lib/systemd/coredump/

— Франсуа

224

В недавнем Ubuntu (12.04 в моем случае) возможно распечатать «Ошибка сегментации (сброшено ядро)», но файл ядра не был создан там, где вы могли бы его ожидать (например, для локально скомпилированной программы).

Это может произойти, если у вас размер основного файла ulimit 0 (вы этого не сделали ulimit -c unlimited) - это значение по умолчанию в Ubuntu. Обычно это подавляет «(ядро сброшено)», что указывает на вашу ошибку, но в Ubuntu файлы ядра отправляются в Apport (систему отчетов о сбоях Ubuntu) через /proc/sys/kernel/core_pattern, и это, похоже, приводит к вводящему в заблуждение сообщению.

Если Apport обнаруживает, что рассматриваемая программа не та, о которой она должна сообщать о сбоях (что, как вы можете видеть, происходит /var/log/apport.log), она прибегает к моделированию поведения ядра по умолчанию при помещении файла ядра в cwd (это делается в сценарии). /usr/share/apport/apport). Это включает в себя соблюдение ulimit, в этом случае он ничего не делает. Но (я предполагаю), что касается ядра, был сгенерирован файл core (и передан для аппроксимации), отсюда и сообщение «Ошибка сегментации (ядро сброшено)».

В конечном счете, PEBKAC забыл установить ulimit, но вводящее в заблуждение сообщение заставило меня подумать, что я на некоторое время схожу с ума, задаваясь вопросом, что съедает мои основные файлы.

(Кроме того, в общем, справочная страница core (5) - man 5 coreэто хорошая справка о том, где заканчивается файл core и почему он не может быть записан.)

— JTN
источник

4

Большое вам спасибо - я столкнулся с той же проблемой. Кстати, Ubuntu 14.04 демонстрирует точно такое же поведение, как и описанное вами.

— Malte Skoruppa

5

В моей установке Ubuntu (измененной 14.04) для этого есть простой временный обходной путь, запустив его sudo service apport stop- после того, как я запустил его, он изменился /proc/sys/kernel/core_patternс канала apport на just core. Полагаю, Apport достаточно умен, чтобы core_patternвременно исправить ситуацию.

— Патрик Коллинз

6

"ulimit -c безлимитный" - именно то, что мне было нужно - спасибо!

— Дейв С

4

Я попробовал каждый подходящий ответ и каждое место в каждом комментарии здесь после выполнения команды ulimit, но все еще не могу найти файл ядра где-нибудь на моем Ubuntu 16.04 LTS ...

— Nagev

2

@ElectricGoat Нет, не знаю. Это плохой дизайн UX, IMO. Система должна просто напечатать путь или не печатать сообщение вообще, если оно не создается. Я добавлю свой собственный ответ, когда или если у меня будет возможность исследовать это дальше.

— Нагев

80

С запуском systemd , есть и другой сценарий. По умолчанию systemd будет хранить дампы ядра в своем журнале, будучи доступным с помощью systemd-coredumpctlкоманды. Определено в файле core_pattern:

$ cat /proc/sys/kernel/core_pattern 
|/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e

Такое поведение можно отключить простым «взломом»:

$ ln -s /dev/null /etc/sysctl.d/50-coredump.conf
$ sysctl -w kernel.core_pattern=core      # or just reboot

Как всегда, размер дампов ядра должен быть равен или превышать размер дампов ядра, как, например, сделано ulimit -c unlimited.

— TIMSS
источник

Этот «взлом» не работал для меня (даже после перезапуска). Я использую Arch Linux и уже запускаю ulimit -c unlimited.

— gsingh2011

@ gsingh2011 Это может быть устаревшим. Я больше не управляю Arch, поэтому не могу сказать, сработает ли это в наши дни. Если вы поймете это, не стесняйтесь обновить меня / нас с новым комментарием.

— Timss

5

@ gsingh2011 Попробуйте 50-coredump.confвместо coredump.conf. Это должно переопределить /lib/sysctl.d/50-coredump.conf. По умолчанию можно восстановить с помощьюsysctl -w kernel.core_pattern=core

— Lekensteyn

Я должен был отключить appport для этого, чтобы работатьsudo service apport stop

— rahul003

51

Написание инструкций для получения дампа ядра под Ubuntu 16.04 LTS :

Как упомянул @jtn в своем ответе, Ubuntu делегирует отображение сбоев в apport , который, в свою очередь, отказывается записывать дамп, поскольку программа не является установленным пакетом.
Чтобы решить эту проблему, мы должны убедиться, что apport также записывает файлы дампа ядра для непакетных программ. Для этого создайте файл ~ / .config / apport / settings со следующим содержимым:
[main] unpackaged=true
Теперь снова закройте вашу программу и увидите, что ваши файлы сбоя генерируются в папке: / var / crash с такими именами, как * .1000.crash . Обратите внимание, что эти файлы не могут быть прочитаны GDB напрямую.
[Необязательно] Чтобы сделать дамп доступным для чтения с помощью gdb, выполните следующую команду:

apport-unpack <location_of_report> <target_directory>

Ссылки: Core_dump - Oracle VM VirtualBox

— ankurrc
источник

3

Это единственное решение, которое сработало для меня в Ubuntu 18.04

— greuze

К какому пользователю относится ~ / относится? Если процесс запускается пользователем root, значит ли это /root/.config/apport/settings?

— Николи

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

— ankurrc

12

Я мог бы подумать о двух следующих возможностях:

Как уже отмечали другие, программа может chdir(). Разрешено ли пользователю, работающему с программой, записывать в каталог, в который она chdir()редактируется? Если нет, он не может создать дамп ядра.
По какой-то странной причине дамп ядра не назван. core.*Вы можете проверить /proc/sys/kernel/core_patternэто. Кроме того, команда find, которую вы назвали, не найдет типичный дамп ядра. Вы должны использовать find / -name "*core.*", так как типичное имя coredumpcore.$PID

— ahans
источник

вот мой шаблон - означает ли это, что файл ядра называется чем-то вроде «PID.signal.userid» вместо core.pid ??? $ cat / proc / sys / kernel / core_pattern / usr / lib / hookCCpp / var / char / abrt% p% s% u

— webminal.org

9

Если вам не хватает дампов ядра для двоичных файлов RHELи при их использовании abrt, убедитесь, что/etc/abrt/abrt-action-save-package-data.conf

содержит

ProcessUnpackaged = yes

Это позволяет создавать отчеты о сбоях (включая дампы ядра) для двоичных файлов, которые не являются частью установленных пакетов (например, локально собранных).

— MRalwasser
источник

6

Для fedora25, я мог бы найти основной файл в

/var/spool/abrt/ccpp-2017-02-16-16:36:51-2974/coredump

где ccpp-2017-02-16-16:36:51-2974" is pattern "%s %c %p %u %g %t %P %согласно `/ proc / sys / kernel / core_pattern '

— Махавир Дараде
источник

5

Мои усилия в WSL были безуспешными.

Для тех, кто работает в подсистеме Windows для Linux (WSL), в настоящее время существует проблема с отсутствующими файлами дампа памяти.

Комментарии указывают на то, что

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

Выпуск Github

Обратная связь для разработчиков Windows

— Брэндон Сорен Калли
источник

5

В Ubuntu18.04 самый простой способ получить файл ядра - ввести команду ниже, чтобы остановить службу apport.

sudo service apport stop

Затем перезапустите приложение, вы получите файл дампа в текущем каталоге.

— Николас Гонг
источник

3

Я на Linux Mint 19 (на основе Ubuntu 18). Я хотел иметь coredumpфайлы в текущей папке. Я должен был сделать две вещи:

Изменить /proc/sys/kernel/core_pattern(по # echo "core.%p.%s.%c.%d.%P > /proc/sys/kernel/core_patternили# sysctl -w kernel.core_pattern=core.%p.%s.%c.%d.%P)
Повышение лимита для размера файла ядра на $ ulimit -c unlimited

Это было написано уже в ответах, но я написал, чтобы подвести итог кратко. Интересно, что изменение лимита не требовало привилегий суперпользователя (согласно /ubuntu/162229/how-do-i-increase-the-open-files-limit-for-a-non-root-user non- root может только снизить лимит, так что это было неожиданно - комментарии по этому поводу приветствуются).

— Мариша
источник

2

ulimit -c unlimited заставил файл ядра корректно появиться в текущем каталоге после "сброса ядра".

— Николя ФЕРХЕЛЬСТ
источник