Отримайте основний дамп / налагодження процесу, убитого oom-кілером

10

Чи є спосіб отримати основний дамп або мати змогу налагодити процес, убитий убивцею?

Або навіть встановити oom-killer, щоб спробувати вбити процес, використовуючи ABRT замість цього?

oom dump

— TrapAlice
джерело

5

Інший підхід полягає у відключенні перезапису пам'яті.

Щоб відновити деяку подобу розуму для управління пам’яттю:

Вимкнути вбивцю OOM ( vm.oom-kill = 0ввести /etc/sysctl.conf)

Відключити overcommit пам'яті (Поміщений vm.overcommit_memory = 2в /etc/sysctl.conf)

Ці параметри змусять Linux вести себе традиційним чином (якщо процес вимагає більше пам'яті, ніж доступно malloc(), не вдасться, і очікується, що процес, що запитує пам'ять, впорається з цим збоєм).
Зауважте, що це потрійне значення:

0 = "Оцініть, якщо у нас достатньо оперативної пам'яті"

1 = "Завжди кажи так"

2 = "скажи" ні ", якщо у нас немає пам'яті"

Це змусить програму впоратися із втратою пам'яті, і, можливо, її журнали / coredump / тощо можуть дати вам щось корисне.

ОНОВЛЕННЯ №1

ПРИМІТКА. Коли у вашої системи не вистачить пам'яті, ви не зможете породити нові процеси! Можливо, ви заблоковані із системи.

— nishantjr
джерело

Це жахлива ідея. Більшість програмного забезпечення, що працює у вашій системі, ймовірно, неправильно обробляє повернене значення після помилки розподілу пам'яті. Це призведе до виникнення кодових шляхів, які практично ніколи не виконуються будь-яким запущеним, і в гіршому випадку навіть може ввести вразливості безпеки у вашій системі від запуску цих неперевірених і несподіваних шляхів коду.

— KJ Tsanaktsidis

4

echo 1 > /proc/sys/vm/oom_dump_tasks

що здається про максимум, який ви можете отримати ядро для відображення на помилках поза пам'яттю.

https://www.kernel.org/doc/Documentation/sysctl/vm.txt

Вмикає системний дамп задачі (виключаючи потоки ядра), який повинен вироблятися, коли ядро виконує вбивство OOM і включає в себе таку інформацію, як pid, uid, tgid, vm size, rss, nr_ptes, swapents, оцінка oom_score_adj та ім'я. Це корисно, щоб визначити, чому вбивця OOM викликали, визначити завдання, яке його викликало, і визначити, чому вбивця OOM обрала завдання, яке воно вбило.

Якщо для цього встановлено нуль, ця інформація придушується. У дуже великих системах з тисячами завдань може бути недоцільним скидання інформації про стан пам'яті для кожної з них. Такі системи не повинні примушувати застосовувати штрафи за ефективність в умовах OOM, коли інформація може не бути бажаною.

Якщо для цього встановлено значення, що не дорівнює нулю, ця інформація відображається всякий раз, коли вбивця OOM насправді вбиває завдання виправлення пам'яті.

— HBruijn
джерело