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

Question

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

228

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

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

ulimit -c unlimited 
ulimit -a

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

webminal.org 14 янв. 2010, в 17:34

Источник

1

Программа вызывает chdir в какой-то момент? Если так, посмотрите там.
William Pursell 14 янв. 2010, в 17:03
2

Программа меняет свой рабочий каталог? Посмотрите там.
Richard Pennington 14 янв. 2010, в 17:03
0

Я бы искал по всему жесткому диску недавний файл;)
Hamish Grubijan 14 янв. 2010, в 17:03
0

да .. программа использует chdir - я проверю там через несколько секунд
webminal.org 14 янв. 2010, в 17:04
1

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

Есть ли способ перенаправить файл дампа ядра в конкретный каталог, скажем / TMP
webminal.org 14 янв. 2010, в 17:30
6

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

Показать ещё 5 комментариев

Теги:

c

linux

coredump

8 ответов

204

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

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

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

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

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

jtn 21 авг. 2013, в 22:09

4

Большое спасибо - я столкнулся с той же проблемой. Кстати, Ubuntu 14.04 демонстрирует точно такое же поведение, как и описанное вами.
Malte Skoruppa 22 июль 2015, в 10:19
4

В моей установке Ubuntu (измененной 14.04) есть простой временный обходной путь для этого, запустив sudo service apport stop - после того, как я запустил это, он изменил /proc/sys/kernel/core_pattern из канала приложения в только core . Полагаю, Apport достаточно умен, чтобы временно исправить core_pattern .
Patrick Collins 22 фев. 2016, в 18:50
5

"ulimit -c безлимитный" - именно то, что мне было нужно - спасибо!
Dave C 20 март 2016, в 18:07
0

Недавно ubuntu записывает ядро в ~/temp/core после того, как вы подняли ulimit . Проверьте журнал в var/log/apport.log (да, у вас должны быть var/log/apport.log на чтение этого файла).
Karl 18 дек. 2016, в 12:34
3

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

@Nagev, я столкнулся с той же проблемой с Ubuntu 14.04. Вы когда-нибудь находили решение?
nico 16 авг. 2017, в 15:19
2

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

спасибо, решил это так: echo core | sudo tee / proc / sys / kernel / core_pattern
Willy Tarreau 15 апр. 2018, в 20:26
1

Brilliant! В Ubuntu 16.04 /var/log/apport.log содержал host pid [...] crashed in a separate mount namespace, ignoring (быстрый поиск не обнаружил ничего полезного в отношении этого сообщения, ни как его обойти) и остановив Служба Apport временно с systemctl stop apport позволила записать дамп ядра в его ожидаемое местоположение.
Ben Johnson 11 май 2018, в 14:48

Показать ещё 7 комментариев

69

С запуском 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 29 дек. 2012, в 15:25

0

Этот «взлом» не работал для меня (даже после перезагрузки). Я использую Arch Linux и уже использую ulimit -c unlimited .
gsingh2011 16 окт. 2013, в 05:15
0

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

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

Я должен был отключить appport для этого, чтобы работать sudo service apport stop
rahul003 02 фев. 2018, в 00:06

Показать ещё 2 комментария

27

Написание инструкций для получения дампа ядра под 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

Ankur Roy Chowdhury 25 нояб. 2017, в 03:07

0

Это единственное решение, которое работало для меня в Ubuntu 18.04
greuze 31 окт. 2018, в 08:58

10

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

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

ahans 14 янв. 2010, в 18:36

0

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

6

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

содержит

ProcessUnpackaged = yes

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

MRalwasser 08 дек. 2016, в 17:54

3

Мои усилия в WSL были неудачными.

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

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

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

Выпуск Github

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

Brandon Søren Culley 04 май 2018, в 02:08

3

Для 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 '

mahaveer darade 16 фев. 2017, в 12:08

Ещё вопросы

Программа вызывает chdir в какой-то момент? Если так, посмотрите там.
Программа меняет свой рабочий каталог? Посмотрите там.
Я бы искал по всему жесткому диску недавний файл;)
да .. программа использует chdir - я проверю там через несколько секунд
ой нет, его там нет ... Я проверил это .. запрограммируйте chdir в / mnt и / я проверил обе директории, но не смог найти файл. Я даже нашел / -name "* core". даже это не показывало мне файл. Программа использует C + sqlite, при этом вставляя значения в дампы ядра. В первый раз говорится об ошибке подтверждения == 0, а об ошибке = 101 во второй раз.
Есть ли способ перенаправить файл дампа ядра в конкретный каталог, скажем / TMP
Да, если вы переопределяете /proc/sys/kernel/core_pattern строкой, начинающейся с /tmp тогда именно туда и пойдут ваши дампы ядра.
Большое спасибо - я столкнулся с той же проблемой. Кстати, Ubuntu 14.04 демонстрирует точно такое же поведение, как и описанное вами.
В моей установке Ubuntu (измененной 14.04) есть простой временный обходной путь для этого, запустив sudo service apport stop - после того, как я запустил это, он изменил /proc/sys/kernel/core_pattern из канала приложения в только core . Полагаю, Apport достаточно умен, чтобы временно исправить core_pattern .
"ulimit -c безлимитный" - именно то, что мне было нужно - спасибо!
Недавно ubuntu записывает ядро в ~/temp/core после того, как вы подняли ulimit . Проверьте журнал в var/log/apport.log (да, у вас должны быть var/log/apport.log на чтение этого файла).
Я попробовал каждый подходящий ответ и каждое место в каждом комментарии здесь после выполнения команды ulimit, но все еще не могу найти файл ядра где-нибудь на моем Ubuntu 16.04 LTS ...
@Nagev, я столкнулся с той же проблемой с Ubuntu 14.04. Вы когда-нибудь находили решение?
@ElectricGoat Нет, не знаю. Это плохой дизайн UX, IMO. Система должна просто напечатать путь или не печатать сообщение вообще, если оно не создается. Я добавлю свой собственный ответ, когда или если у меня будет возможность исследовать это дальше.
спасибо, решил это так: echo core | sudo tee / proc / sys / kernel / core_pattern
Brilliant! В Ubuntu 16.04 /var/log/apport.log содержал host pid [...] crashed in a separate mount namespace, ignoring (быстрый поиск не обнаружил ничего полезного в отношении этого сообщения, ни как его обойти) и остановив Служба Apport временно с systemctl stop apport позволила записать дамп ядра в его ожидаемое местоположение.
Этот «взлом» не работал для меня (даже после перезагрузки). Я использую Arch Linux и уже использую ulimit -c unlimited .
@ gsingh2011 Это может быть устаревшим. Я больше не управляю Arch, поэтому не могу сказать, сработает ли это в наши дни. Если вы поймете это, не стесняйтесь обновить меня / нас с новым комментарием.
@ gsingh2011 Попробуйте 50-coredump.conf вместо coredump.conf . Это должно переопределить /lib/sysctl.d/50-coredump.conf . По умолчанию можно восстановить с помощью sysctl -w kernel.core_pattern=core
Я должен был отключить appport для этого, чтобы работать sudo service apport stop
Это единственное решение, которое работало для меня в Ubuntu 18.04
вот мой шаблон - означает ли это, что файл ядра называется как «PID.signal.userid» вместо core.pid ??? $ cat / proc / sys / kernel / core_pattern / usr / lib / hookCCpp / var / char / abrt% p% s% u

ephemient · Accepted Answer · 2010-01-14T22-25-00.000Z

Прочитайте /usr/src/linux/Документация/sysctl/kernel.txt.

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

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

Вместо того, чтобы записывать основной дамп на диск, ваша система настроена на отправку его в программу abrt. Автоматический отчет об ошибках, возможно, не так документирован как должен быть...

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

да, я отредактировал core_pattern со следующим содержимым echo "core.% e.% p"> / proc / sys / kernel / core_pattern .. теперь он создает файл дампа ядра в самом текущем каталоге. с именем "core.giis.12344" и т. д. Спасибо всем за ваши ответы / комментарии / советы.
Отметим, что программа aborat fedora 18 хранит дампы ядра в /var/spool/abrt/ вместо /var/cache/abrt
Есть ли способ разрешить пользователям настраивать это для себя, а не всем, кому приходится использовать конфигурацию системы?
Когда эта команда запущена и процесс запущен, stdout и stderr не открываются по умолчанию? Я вижу, как происходят очень странные вещи. когда я использую dup2 из stderr и stdout в свой пользовательский файл (applog.txt), данные, которые я записываю в другой файл (mycore.BIN), перенаправляются в файл, который я использовал для перехвата stdout & stderr (applog.txt) , Есть ли хорошее чтение об этом? Пожалуйста, предложите. Спасибо
systemd в archlinux хранит coredumps в /var/lib/systemd/coredump/
systemd в Debian также использует /var/lib/systemd/coredump/