Failed with result 'oom-kill' — причины и решение

Что это значит

Состояние доступно начиная с systemd 243: до него такие случаи выглядели как обычный signal с KILL. Если ваша версия старше, ориентируйтесь на записи ядра.

Вероятные причины

По порядку: сверху то, что встречается чаще.

Служба упёрлась в собственный предел памяти

При заданном MemoryMax= ядро убивает процесс, как только группа превышает предел, даже если на машине памяти много.
Кончилась память на всей машине

Ядро выбирает жертву по оценке и убивает её. Убитой может оказаться совсем не та служба, которая память израсходовала.
Утечка памяти в самой службе

Потребление растёт монотонно и упирается в предел через часы или дни работы. Перезапуск помогает ненадолго.

Диагностика

Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.

Ядро называет процесс, объём памяти и контекст: срез службы или вся машина.

journalctl -k -b --no-pager | grep -i "killed process"

Предел и фактическое потребление: сразу видно, был ли упор в ограничение.

systemctl show myapp.service -p MemoryMax -p MemoryPeak -p MemoryCurrent

Кто на машине потребляет память сейчас — помогает найти настоящего виновника.

systemd-cgtop -1 --order=memory | head -12

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Служба упёрлась в собственный предел памяти

Почему происходит: При заданном MemoryMax= ядро убивает процесс, как только группа превышает предел, даже если на машине памяти много.

Как проверить

Сравните предел и пиковое потребление.

systemctl show myapp.service -p MemoryMax -p MemoryPeak -p Slice
journalctl -k -b --no-pager | grep -i "memory cgroup out of memory"

Как исправить

Поднимите предел до потребления с запасом или уменьшите потребление настройками программы. Строка «Memory cgroup out of memory» в записях ядра — признак именно этого случая.

sudo systemctl edit myapp.service   # MemoryMax=2G

2. Кончилась память на всей машине

Почему происходит: Ядро выбирает жертву по оценке и убивает её. Убитой может оказаться совсем не та служба, которая память израсходовала.

Как проверить

Посмотрите записи ядра и общее потребление по срезам.

journalctl -k -b --no-pager | grep -iE "out of memory|oom_reaper"
systemd-cgtop -1 --order=memory | head -10

Как исправить: Найдите настоящего потребителя и ограничьте его через MemoryMax=. Добавление подкачки помогает пережить пики, но не отменяет разбор.

3. Утечка памяти в самой службе

Почему происходит: Потребление растёт монотонно и упирается в предел через часы или дни работы. Перезапуск помогает ненадолго.

Как проверить

Посмотрите, как менялось потребление между перезапусками.

systemctl show myapp.service -p MemoryCurrent -p MemoryPeak -p NRestarts
journalctl -u myapp.service --no-pager | grep -i "oom" | tail -5

Как исправить: Исправлять нужно программу. Пока идёт разбор, спасает управляемый перезапуск по расписанию через RuntimeMaxSec= — это честнее, чем ждать очередной смерти от OOM.

Пример вывода

Служба превысила собственный предел памяти. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.

× indexer.service - Search indexer
     Active: failed (Result: oom-kill) since Mon 2026-09-15 21:30:02 MSK; 1min ago
   Main PID: 21900 (code=killed, signal=KILL)
     Memory: 1.0G (max: 1.0G available: 0B)

kernel: Memory cgroup out of memory: Killed process 21900 (indexer)
systemd[1]: indexer.service: A process of this unit has been killed by the OOM killer.
systemd[1]: indexer.service: Failed with result 'oom-kill'.

Связанные ошибки

signal=KILL (status=9/KILL) в systemd Процесс службы убит сигналом KILL. Кто мог его послать: OOM-killer, таймаут остановки systemd, администратор.
status=204/MEMORY в systemd Код 204/MEMORY: systemd не смог выделить память при подготовке запуска службы. Что проверять на машине и в unit-файле.
status=206/OOM_ADJUST в systemd Код 206/OOM_ADJUST: не удалось изменить оценку OOM для процесса службы. Обычно мешают права или значение вне диапазона.
Failed with result 'exit-code' Состояние exit-code: служба завершилась с ненулевым кодом. Что это сообщение значит и где искать настоящую причину.
Failed with result 'timeout' Состояние timeout: служба не уложилась в отведённое время при запуске, остановке или перезагрузке настроек.
MySQL убит из-за памяти: буферный пул больше доступной памяти MySQL падает сразу после старта или через минуты: размер innodb_buffer_pool_size превышает память машины.
start-limit-hit: служба заблокирована после серии перезапусков Состояние start-limit-hit и сообщение start request repeated too quickly: systemd перестал перезапускать службу. Как разблокировать и найти исходную причину.
Служба active, но не работает: обёртки и oneshot Почему состояние active не означает работающую программу: oneshot с RemainAfterExit, обёртки, потерянный главный процесс.

Где встречается чаще всего

Источники

systemd.service(5)
Значение oom-kill в таблице Result и параметр OOMPolicy=. официальная документация, systemd 255
сверено 15 сентября 2026
systemd.resource-control(5)
MemoryMax=, MemoryHigh= и поведение при упоре в предел. официальная документация, systemd 255
сверено 15 сентября 2026
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Воспроизведено на службе с MemoryMax=64M и потреблением выше предела. собственная проверка, systemd 255
сверено 15 сентября 2026