Core скинуто, але основний файл не знаходиться в поточному каталозі?

277

Під час запуску програми C він говорить "(ядро скинуто)", але я не бачу жодного файлу під поточним контуром.

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

ulimit -c unlimited 
ulimit -a

Я також спробував знайти файл з назвою "core", але я не отримав файл, який викинув ядро?
Будь-яка допомога, де мій основний файл?

c linux coredump

— webminal.org
джерело

1

Програма чи викликає chdir в якийсь момент? Якщо так, подивіться там.

— Вільям Перселл

2

Чи змінює програма свою робочу директорію? Подивіться туди.

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

Я б шукав у всьому жорсткому диску останній файл;)

— Хаміш Грубіян

1

oops ні його там немає ... Я перевірив .. програма chdir до / mnt і / я перевірив обидва каталоги, але не зміг знайти файл. Я навіть знайшов / * ім’я "* core". навіть це не показало мені файл. Програма використовує C + sqlite, при цьому вставляючи значення в основний демпінг, вона вперше заявила про помилку твердження = 0 і про помилку = 101 вдруге ..

— webminal.org

7

Так, якщо ви перекриєте /proc/sys/kernel/core_patternрядок, починаючи з /tmpцього, то саме тут перейдуть ваші основні демпфи.

— ефемія

240

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

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

Якщо перший символ шаблону є "|", ядро буде розглядати решту шаблону як команду для запуску. Основний дамп буде записаний на стандартний вхід цієї програми замість файлу.

Замість того, щоб записувати основний дамп на диск, ваша система налаштована таким чином, щоб надіслати його abrtпрограмі. Автоматизований інструмент звітності про помилки , можливо, не такий документально підтверджений, як це має бути ...

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

— ефемієнт
джерело

30

так, я відредагував core_pattern із наступним змістом відлунюється "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 у coredumps магазину archlinux в/var/lib/systemd/coredump/

— Франсуа

224

На останньому Ubuntu (12.04 в моєму випадку) можливе друкування "Помилки сегментації (ядро скинуто)", але не створено жодного основного файлу, де ви могли би очікувати такого (наприклад, для локально складеної програми).

Це може статися, якщо у вас розмір основного файлу не перевищує 0 (ви ще цього не зробили ulimit -c unlimited) - це типово для Ubuntu. Зазвичай це пригнічує "(ядро скинуто)", вказуючи на вашу помилку, але на Ubuntu основні файли передаються через Apport (система звітування про аварії Ubuntu) через /proc/sys/kernel/core_pattern, і це, здається, викликає оманливе повідомлення.

Якщо Apport виявить, що програма, про яку йдеться, не є такою, про яку слід повідомляти про збої (що ви можете бачити, що відбувається в /var/log/apport.log), вона повертається назад до імітації поведінки ядра за замовчуванням при введенні основного файлу в cwd (це робиться в сценарії /usr/share/apport/apport). Сюди входить шанування ulimit, і в цьому випадку вона нічого не робить. Але (я припускаю) що стосується ядра, то було створено основний файл (і покладено на додаток), отже, повідомлення "Несправність сегментації (ядро скинуто)".

В кінцевому рахунку PEBKAC за те, що забув встановити пробну версію, але оманливе повідомлення змусило мене думати, що я ненадовго зійшов з розуму, цікавившись, що їсть мої основні файли.

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

— jtn
джерело

4

Дуже дякую - я зіткнувся з тією самою проблемою. Btw, Ubuntu 14.04 демонструє абсолютно таку ж поведінку, як і описану вами.

— Malte Skoruppa

5

У моїй установці Ubuntu (модифікована 14.04) є легкий тимчасовий спосіб вирішити це, запустивши sudo service apport stop--- після того, як я запустив це, він змінився /proc/sys/kernel/core_patternз труби прикладного на просто core. Apport досить розумний, щоб core_patternтимчасово виправити , я думаю.

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

6

"ulimit -c unlimited" - саме те, що мені було потрібно - Дякую!

— Дейв C

4

Я перепробував усі відповідні відповіді та кожне місце розташування в кожному коментарі тут, виконуючи команду ulimit, але все ще не можу знайти

— ядрового

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.

— темс
джерело

Цей "злом" не спрацював для мене (навіть після перезавантаження). Я запускаю 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

Мені довелося вимкнути додаток, щоб це працювалоsudo service apport stop

— rahul003

51

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

Як згадував @jtn у своїй відповіді, Ubuntu делегує дисплей збоїв для присвоєння , який, у свою чергу, відмовляється писати дамп, оскільки програма не є встановленим пакетом.
Щоб усунути проблему, нам потрібно переконатися, що 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

— ахани
джерело

ось моя картина - чи означає це основний файл названий чимось на зразок "PID.signal.userid" замість core.pid ??? $ cat / proc / sys / kernel / core_pattern / usr / lib / hockCCpp / 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 '

— mahaveer darade
джерело

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 зробив файл ядра правильно відображатися в поточному каталозі після "скидання ядра".

— Ніколас ВЕРХЕЛСТ
джерело