PID убитого по out‑of‑memory‑процессу можно найти с помощью одной команды. Если есть логи с PID процесса, то найти пострадавшего можно, запустив ещё одну команду grep.
OOM‑киллер безжалостен. Кажется, что он выбирает процесс случайным образом — тот, который нужно «пристрелить» на машине. На самом деле под капотом он работает совсем по‑другому, и случайности в его действиях нет. Взглянув на таблицу процессов и пару файлов, можно предсказать, какой процесс будет убит, если сейчас случится OOM.
Для поиска уже потерянного процесса эти знания бесполезны. Когда я доберусь до поиска, состояние машины уже поменяется. Как минимум в списке процессов не будет того, кого «пристрелил» OOM‑киллер.
PID процесса, убитого OOM, и имя приложения можно найти с помощью одной команды. В случае с приложением на Python в выдаче будет python. Дополнительный фильтр может помочь в поисках, но слабо. Нужно заранее готовить логи к подобным разборам: добавить в них PID процесса.
dmesg -T | egrep -i 'killed process'
Дальше — дело техники. Из вывода берём подходящий по времени PID, идём в логи и ищем, что такого запускалось с этим PID. Для этого должны быть логи, а в логах — PID процесса.
Почему бывает полезно найти убитый процесс? Для веб‑приложений, запускаемых под супервизором, это не принципиально: прибили один процесс — на его месте запустился новый.
Но если прибит важный долгий расчёт, который запустится повторно только через несколько часов? Если найти такой упавший расчёт, то можно предупредить пользователей, что результаты будут с опозданием, и перезапустить его, не дожидаясь следующего запуска по расписанию.
Процессы не убиваются случайным образом. Для этого используется скоринг процесса: число растёт, если процесс потребляет много памяти, и падает, если процесс долго живёт в системе. Более подробно про скоринг и работу киллера читайте в статье Taming the OOM killer на LWN.