Що вбило мій процес і чому?


614

Моя програма працює як фоновий процес в Linux. Наразі він запускається в командному рядку у вікні терміналу.

Нещодавно користувач деякий час виконував додаток, і він загадково помер. Текст:

Загинув

був на терміналі. Це сталося два рази. Я запитав, чи хтось на іншому Терміналі використовував команду kill для вбивства процесу? Ні.

За яких умов Linux вирішить вбити мій процес? Я вважаю, що оболонка відображалася "вбита", оскільки процес загинув після отримання сигналу вбивства (9). Якщо Linux надіслав сигнал вбивства, чи повинно бути десь у системному журналі повідомлення, яке пояснює, чому він був убитий?


23
linux вбив мій процес і ввійшов до нього / var / log / messages на redhat
Дін Хіллер

1
Дивіться також цю відповідь на unix.stackexchange.com.
Річард

У цій події є 3 гравці: (1) Процес, який (загальна причина) займає занадто багато пам’яті і спричиняє стан OOM (2) Ядро, яке надсилає SIGKILL (сигнал 9), щоб його припинити, і записує факт у деяку систему log like /var/log/messages(3) Оболонка, під якою запускався процес - це процес, який друкує Killedсповіщення, коли статус виходу з waitpid(2)вказує, що дочірній процес помер від сигналу 9.
arielf

Прочитавши відповідь @ DeanHiller, я знайшов повідомлення журналу на Ubuntu під/var/log/syslog
Діней

Відповіді:


403

Якщо користувач або sysadmin не вбили програму, ядро ​​може мати. Ядро вбиває процес лише за виняткових обставин, таких як екстремальне голодування ресурсів (подумайте, пам'ять пам’яті + своп).


25
Якщо ядро ​​вбило процес, чи помістило б його повідомлення в журнал десь?
sbq

186
Я щойно написав програму, яка благала пам'ять у нескінченному циклі. Після того, як система повільно потихеньку, у терміналі відображається "Убитий", і процес припиняється. Файл /var/log/kern.log містив багато інформації про припинення. -Дякую за вказівник.
sbq

6
Це майже точно. Я багато бачив цього під час TAing. Багато студентів забудуть звільнити свої об'єкти, і додатки зрештою дістануть до 3 ГБ використання віртуальної пам'яті. Як тільки він потрапив у цю точку, його вбили.
Герм

8
Коли «програма просто виходить з ладу», то є операційна система на насправді вбити процес!
Бернд Джендріссек

79
Використовуйте dmesgдля перегляду журналу ядра: тут я знаходжу свої процеси в питоні, вбиті ядром через надзвичайне споживання віртуальної пам'яті.
caneta

273

Спробуйте:

dmesg -T| grep -E -i -B100 'killed process'

Де -B100позначає кількість рядків до того, як сталося вбивство.

Опустіть -T на Mac OS.


6
FYI, від info egrep: "egrep - це те саме, що і grep -E. ... Пряме виклик як egrep, так і fgrep застаріле"
Air

9
У випадку простого шаблону, який 'killed process'ви можете просто використовувати grepзамість egrepжодних інших змін. Для більш складного шаблону ви б замінили, наприклад, egrep -i -B100 'foo|ba[rz]'на grep -E -i -B100 'foo|ba[rz]'. У цьому питанні дано детальнішу інформацію.
Повітря

2
Я б також запропонував використовувати dmesg -Tдля отримання читаних часових позначок
gukoff

171

Це виглядає як гарна стаття на тему: Приручення вбивці ООМ .

Суть у тому, що Linux переборюєпам'ять. Коли процес вимагає більше місця, Linux надасть йому цей простір, навіть якщо на нього вимагає інший процес, за умови, що ніхто фактично не використовує всю пам'ять, яку він вимагає. Процес отримає ексклюзивне використання виділеної ним пам’яті, коли вона фактично використовує її, а не тоді, коли вона вимагає. Це робить розподіл швидким і може давати вам змогу "обдурити" та виділити більше пам'яті, ніж ви насправді маєте. Однак, як тільки процеси почнуть використовувати цю пам'ять, Linux може зрозуміти, що надто великодушно виділяє пам'ять, якої у неї немає, і доведеться вибити процес, щоб звільнити деяку частину. Процес вбивства базується на оцінці з урахуванням часу виконання (тривалі процеси безпечніші), використання пам'яті (жадібні процеси менш безпечні) та кількох інших факторів, включаючи значення, яке ви можете скорегувати, щоб зробити процес, менший за ймовірність, був убитий. Все це описано в статті набагато детальніше.

Редагувати: І ось ще одна стаття, яка досить добре пояснює, як обраний процес (анотовано з деякими прикладами коду ядра). Чудова річ у тому, що вона включає коментар до міркувань різних badness()правил.


3
Я дуже люблю посилання на статтю. Я б запропонував усім, кого цікавить тема, прочитати їх, особливо коментарі до статті lwn.
Джон Брінгхерст

4
"Linux дасть йому простір, навіть якщо це вимагає інший процес" Це не зовсім так, як працює віртуальна пам'ять ...
Mooing Duck

1
стаття досить стара (2009), і не всі функціональні можливості, запропоновані в статті, є основними.
Олексій

50

Дозвольте мені спочатку пояснити, коли і чому викликають OOMKiller?

Скажімо, у вас 512 оперативної пам’яті + 1 Гб пам'яті. Тож теоретично ваш процесор має доступ до загальної кількості 1,5 ГБ віртуальної пам'яті.

Зараз деякий час все працює нормально в межах 1,5 ГБ загальної пам’яті. Але раптом (або поступово) ваша система почала споживати все більше і більше пам’яті, і вона досягла приблизно 95% загальної пам'яті.

Тепер скажіть, що будь-який процес вимагає великих розмірів пам'яті від ядра. Ядро перевірить наявну пам’ять і виявить, що немає способу виділити ваш процес більше пам'яті. Таким чином, він спробує звільнити деякий виклик / виклик пам'яті OOMKiller ( http://linux-mm.org/OOM ).

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

Де я можу знайти журнали OOMKiller?

Зазвичай в каталозі / var / log. Або /var/log/kern.log або / var / log / dmesg

Сподіваюся, що це вам допоможе.

Деякі типові рішення:

  1. Збільшити пам'ять (не змінювати місцями)
  2. Знайдіть витоки пам'яті у вашій програмі та виправте їх
  3. Обмежити пам'ять, яку може спожити будь-який процес (наприклад, пам'ять JVM можна обмежити за допомогою JAVA_OPTS)
  4. Перегляньте журнали та google :)

17

Це менеджер пам'яті Linux з пам'яті (OOM) . Ваш процес був обраний через « поганість » - поєднання останніх, розмірів резидентів (використовувана пам'ять, а не просто виділена) та інших факторів.

sudo journalctl -xb

Ви побачите повідомлення типу:

Jul 20 11:05:00 someapp kernel: Mem-Info:
Jul 20 11:05:00 someapp kernel: Node 0 DMA per-cpu:
Jul 20 11:05:00 someapp kernel: CPU    0: hi:    0, btch:   1 usd:   0
Jul 20 11:05:00 someapp kernel: Node 0 DMA32 per-cpu:
Jul 20 11:05:00 someapp kernel: CPU    0: hi:  186, btch:  31 usd:  30
Jul 20 11:05:00 someapp kernel: active_anon:206043 inactive_anon:6347 isolated_anon:0
                                    active_file:722 inactive_file:4126 isolated_file:0
                                    unevictable:0 dirty:5 writeback:0 unstable:0
                                    free:12202 slab_reclaimable:3849 slab_unreclaimable:14574
                                    mapped:792 shmem:12802 pagetables:1651 bounce:0
                                    free_cma:0
Jul 20 11:05:00 someapp kernel: Node 0 DMA free:4576kB min:708kB low:884kB high:1060kB active_anon:10012kB inactive_anon:488kB active_file:4kB inactive_file:4kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present
Jul 20 11:05:00 someapp kernel: lowmem_reserve[]: 0 968 968 968
Jul 20 11:05:00 someapp kernel: Node 0 DMA32 free:44232kB min:44344kB low:55428kB high:66516kB active_anon:814160kB inactive_anon:24900kB active_file:2884kB inactive_file:16500kB unevictable:0kB isolated(anon):0kB isolated
Jul 20 11:05:00 someapp kernel: lowmem_reserve[]: 0 0 0 0
Jul 20 11:05:00 someapp kernel: Node 0 DMA: 17*4kB (UEM) 22*8kB (UEM) 15*16kB (UEM) 12*32kB (UEM) 8*64kB (E) 9*128kB (UEM) 2*256kB (UE) 3*512kB (UM) 0*1024kB 0*2048kB 0*4096kB = 4580kB
Jul 20 11:05:00 someapp kernel: Node 0 DMA32: 216*4kB (UE) 601*8kB (UE) 448*16kB (UE) 311*32kB (UEM) 135*64kB (UEM) 74*128kB (UEM) 5*256kB (EM) 0*512kB 0*1024kB 1*2048kB (R) 0*4096kB = 44232kB
Jul 20 11:05:00 someapp kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
Jul 20 11:05:00 someapp kernel: 17656 total pagecache pages
Jul 20 11:05:00 someapp kernel: 0 pages in swap cache
Jul 20 11:05:00 someapp kernel: Swap cache stats: add 0, delete 0, find 0/0
Jul 20 11:05:00 someapp kernel: Free swap  = 0kB
Jul 20 11:05:00 someapp kernel: Total swap = 0kB
Jul 20 11:05:00 someapp kernel: 262141 pages RAM
Jul 20 11:05:00 someapp kernel: 7645 pages reserved
Jul 20 11:05:00 someapp kernel: 264073 pages shared
Jul 20 11:05:00 someapp kernel: 240240 pages non-shared
Jul 20 11:05:00 someapp kernel: [ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name
Jul 20 11:05:00 someapp kernel: [  241]     0   241    13581     1610      26        0             0 systemd-journal
Jul 20 11:05:00 someapp kernel: [  246]     0   246    10494      133      22        0         -1000 systemd-udevd
Jul 20 11:05:00 someapp kernel: [  264]     0   264    29174      121      26        0         -1000 auditd
Jul 20 11:05:00 someapp kernel: [  342]     0   342    94449      466      67        0             0 NetworkManager
Jul 20 11:05:00 someapp kernel: [  346]     0   346   137495     3125      88        0             0 tuned
Jul 20 11:05:00 someapp kernel: [  348]     0   348    79595      726      60        0             0 rsyslogd
Jul 20 11:05:00 someapp kernel: [  353]    70   353     6986       72      19        0             0 avahi-daemon
Jul 20 11:05:00 someapp kernel: [  362]    70   362     6986       58      18        0             0 avahi-daemon
Jul 20 11:05:00 someapp kernel: [  378]     0   378     1621       25       8        0             0 iprinit
Jul 20 11:05:00 someapp kernel: [  380]     0   380     1621       26       9        0             0 iprupdate
Jul 20 11:05:00 someapp kernel: [  384]    81   384     6676      142      18        0          -900 dbus-daemon
Jul 20 11:05:00 someapp kernel: [  385]     0   385     8671       83      21        0             0 systemd-logind
Jul 20 11:05:00 someapp kernel: [  386]     0   386    31573      153      15        0             0 crond
Jul 20 11:05:00 someapp kernel: [  391]   999   391   128531     2440      48        0             0 polkitd
Jul 20 11:05:00 someapp kernel: [  400]     0   400     9781       23       8        0             0 iprdump
Jul 20 11:05:00 someapp kernel: [  419]     0   419    27501       32      10        0             0 agetty
Jul 20 11:05:00 someapp kernel: [  855]     0   855    22883      258      43        0             0 master
Jul 20 11:05:00 someapp kernel: [  862]    89   862    22926      254      44        0             0 qmgr
Jul 20 11:05:00 someapp kernel: [23631]     0 23631    20698      211      43        0         -1000 sshd
Jul 20 11:05:00 someapp kernel: [12884]     0 12884    81885     3754      80        0             0 firewalld
Jul 20 11:05:00 someapp kernel: [18130]     0 18130    33359      291      65        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18132]  1000 18132    33791      748      64        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18133]  1000 18133    28867      122      13        0             0 bash
Jul 20 11:05:00 someapp kernel: [18428]    99 18428   208627    42909     151        0             0 node
Jul 20 11:05:00 someapp kernel: [18486]    89 18486    22909      250      46        0             0 pickup
Jul 20 11:05:00 someapp kernel: [18515]  1000 18515   352905   141851     470        0             0 npm
Jul 20 11:05:00 someapp kernel: [18520]     0 18520    33359      291      66        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18522]  1000 18522    33359      294      64        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18523]  1000 18523    28866      115      12        0             0 bash
Jul 20 11:05:00 someapp kernel: Out of memory: Kill process 18515 (npm) score 559 or sacrifice child
Jul 20 11:05:00 someapp kernel: Killed process 18515 (npm) total-vm:1411620kB, anon-rss:567404kB, file-rss:0kB

12

Як заявили dwc та Адам Яскевич, винуватець, швидше за все, вбивця ООМ. Однак наступне питання, що випливає, таке: як я запобігти цьому?

Існує кілька способів:

  1. Дайте вашій системі більше оперативної пам’яті, якщо можете (легко, якщо її VM)
  2. Переконайтесь, що вбивця OOM обрав інший процес.
  3. Вимкніть вбивцю OOM
  4. Виберіть дистрибутив Linux, який постачається з вимкненим OOM Killer.

Завдяки цій статті я виявив, що це особливо просто у виконанні .


2
Це була оперативна пам’ять для мене. Я модернізував від 2 до 4 Гб оперативної пам’яті і проблема усунена. Тепер проблема полягає в рахунку: P
Gus

9

Модуль PAM для обмеження ресурсів спричинив саме ті результати, які ви описали: Мій процес загадково загинув із текстом Убитий у вікні консолі. Жодного виходу журналу, ні в syslog, ні в kern.log . Верхня програма допомогла мені дізнатися , що саме після того, як одна хвилина використання процесора мій процес гине.


8

Такий інструмент, як systemtap (або трекер), може контролювати логіку передачі сигналу ядра та звітувати. наприклад, https://sourceware.org/systemtap/examples/process/sigmon.stp

# stap .../sigmon.stp -x 31994 SIGKILL
   SPID     SNAME            RPID  RNAME            SIGNUM SIGNAME
   5609     bash             31994 find             9      SIGKILL

Блок фільтрації ifв цьому сценарії може бути відрегульований за смаком або усунутий, щоб простежити системний трафік сигналу. Причини можна додатково виділити, збираючи зворотні звороти (додайте print_backtrace()а / та print_ubacktrace()до зонда, відповідно для ядра та користувальницького простору).


4

У середовищі lsf (інтерактивне чи інше), якщо програма перевищує використання пам'яті понад деякий попередньо встановлений поріг адміністраторами в черзі або запитом на ресурс під час подання в чергу, процеси будуть вбиті, щоб інші користувачі не стали жертвою потенціалу тікати. Він не завжди надсилає електронне повідомлення, коли це робить, залежно від способу налаштування.

Одне рішення в цьому випадку - знайти чергу з більшими ресурсами або визначити більші потреби в ресурсі.

Ви також можете переглянути man ulimit

Хоча я не пам'ятаю, ulimitщоб Killedце минуло певний час, оскільки мені це було потрібно.


2

У нас виникали повторювані проблеми в Linux на клієнтському сайті (Red Hat, я думаю), коли OOMKiller (вбивця поза пам'яті) вбив і наше основне додаток (тобто причину існування сервера), і його процеси в базі даних.

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

Я не є експертом Linux, але я скоріше зібрав алгоритм для вирішення, коли щось вбити, а що вбити - складний. Крім того, мені сказали (я не можу говорити про точність цього), що OOMKiller запікається в ядро, і ви не можете просто не запустити його.


1
IIRC, OOMKiller використовується лише в крайньому випадку. Я думаю, що система навіть надсилатиме сигнал різним додаткам із проханням віддати деякі ресурси, перш ніж вона буде змушена викликати OOMKiller. Візьміть із собою зерно солі, як це було давно ...
rmeador

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

6
Запустити oomkiller досить просто. echo "2" > /proc/sys/vm/overcommit_memory
R .. GitHub СТОП ДОПОМОГА ЛІС

Red Hat не хоче дозволити його змінити: sudo echo "2" > /proc/sys/vm/overcommit_memory/ proc / sys / vm / overcommit_memory: Дозвіл відхилено
Brent Faust

2
Спробуйтеecho 2 | sudo tee /proc/sys/vm/overcommit_memory
Hypershadsy

2

У моєму випадку це відбувалося з працівником черги Ларавеля. Системні журнали не згадували жодного вбивства, тому я подивився далі, і виявилося, що працівник в основному вбивав себе через роботу, яка перевищила межу пам'яті (яка за замовчуванням встановлена ​​на 128 М).

Запуск робітника черги з --timeout=600і --memory=1024вирішив проблему для мене.


0

Користувач має можливість вбивати власні програми, використовуючи kill або Control + C, але у мене складається враження, що це не те, що сталося, і що користувач скаржився на вас.

root має змогу вбивати програми, звичайно, але якщо хтось має root на вашій машині і вбиває речі, у вас є більші проблеми.

Якщо ви не sysadmin, sysadmin, можливо, встановив квоти на використання процесора, оперативної пам’яті, використання диска ort та автоматичного вбивства, що перевищує їх.

Крім цих здогадок, я не впевнений без додаткової інформації про програму.


6
Як я пам'ятаю, CTRL-C надсилає інше вбивство, ніж повідомлялося про ОП (SIGINT (2), тоді як програма отримує SIGKILL (9)).
Powerlord

0

Я стикався з цією проблемою останнім часом. Нарешті, я виявив, що мої процеси були вбиті одразу після автоматичного виклику оновлення шиншири Opensuse. Щоб відключити оновлення блискавки вирішив мою проблему.


Я бачу те саме питання. Як ви відстежили, який процес вбив ваш процес? Здається, є інструмент для перевірки того, хто надсилає SIGKILL до процесу.
Howy

0

Вирішили цю проблему, збільшивши розмір свопу :

/ubuntu/1075505/how-do-i-increase-swapfile-in-ubuntu-18-04


3
Будь-ласка, не публікуйте відповідей, що стосуються лише посилань, на інші питання обміну стеками. Натомість включіть сюди основні частини відповіді та підстройте відповідь на це конкретне запитання.
подвійний звуковий сигнал
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.