отримувати сигнал перед тим, як процес буде вбитий вбивцею / групами OOM

У нашому кластері ми обмежуємо ресурси процесів, наприклад, пам'ять ( memory.limit_in_bytes).

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

Чи є спосіб отримати сигнал, перш ніж мій процес буде вбито? (Так само, як і -notifyваріант для SGEqsub , який надсилатиметься SIGUSR1до вбиття процесу.)

Я читав /dev/mem_notify тут про це, але у мене його немає - чи є ще щось інше? Я також читав це, що здається дещо актуальним.

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

Одне вирішення, яким я зараз користуюся, - це невеликий скрипт, який часто перевіряє, чи я близький (95%) до межі, і якщо так, він надсилає процес a SIGUSR1. У Bash я запускаю цей сценарій у фоновому режимі ( cgroup-mem-limit-watcher.py &), щоб він спостерігав за іншими програмами в тій самій групі, і він автоматично закривається, коли батьківський процес Bash гине.

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

Подивитися:

https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt

Вбивця OOM посилає SIGKILL, оскільки в іншому випадку це буде контрпродуктивно, щоб дати можливість проблемній програмі продовжувати вибір.

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

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