Read a Linux Process's OOM-Killer Score Safely

A process about to be killed by the OOM-killer gets no warning, but /proc/PID/oom_score tells you how likely that is before it happens. This walkthrough is entirely read-only: it will not change process policy, restart a service or need root in the normal case. Allow about ten minutes.

You need a shell, a Linux system with /proc mounted, and either a process ID or permission to inspect the process you pick. It follows the installed proc_pid_oom_score(5) page from the manpages package version 6.7-2, tested on kernel 6.8.0-139-generic. The score is live kernel state, so it can change between reads.

1. Read the score for your own shell

Start with a process you own. The shell expands $$ to its own PID, so you are not guessing a number:

$ printf 'PID: %s\n' "$$"
$ cat "/proc/$$/oom_score"
666

Your number will differ. The file holds the current score the kernel uses when weighing this process for the out-of-memory killer. Higher means more likely to be picked. It is a ranking input, not a countdown, a priority guarantee or a promise that the process will actually die.

Checkpoint: repeat the read and confirm it succeeds without changing anything:

$ test -r "/proc/$$/oom_score" && echo readable
readable

2. Inspect a known process

For another process, swap a real numeric PID in for 1234. Ask ps which process that actually is before you read the score:

$ PID='1234'
$ ps -p "$PID" -o pid=,comm=
 1234 example-service
$ cat "/proc/$PID/oom_score"
512

Use elevated privileges only when your host's policy allows it and you have a clear reason:

$ sudo cat "/proc/$PID/oom_score"

Warning: sudo only changes who performs the read. It does not lower the score, protect the process, or stop the OOM-killer choosing it.

3. Read the adjustment separately

The score also reflects the process's oom_score_adj setting, or the older oom_adj setting on systems that still expose it. Read the adjustment as its own value rather than folding it into the score by hand:

$ printf 'score: '
$ cat "/proc/$$/oom_score"
score: 666
$ printf 'adjustment: '
$ cat "/proc/$$/oom_score_adj"
adjustment: 0

The adjustment is not the same field as oom_score. Do not add the two numbers together and call the result a kernel score. The kernel calculates the score from memory use and its own rules, then folds in the adjustment when deciding how desirable a candidate is for reclaim by killing.

Checkpoint: record both values with one small command, so a later comparison has a timestamp and a PID to anchor it:

$ PID=$$
$ printf 'pid=%s score=' "$PID"
$ cat "/proc/$PID/oom_score"
$ printf 'pid=%s adjustment=' "$PID"
$ cat "/proc/$PID/oom_score_adj"
pid=4161951 score=666
pid=4161951 adjustment=0

The exact numbers and PID will vary. If the process changes its memory use, or another process changes its adjustment, a later reading can come out different.

4. Compare processes without overclaiming

A side-by-side reading can explain why two processes look more or less exposed during memory pressure. Capture identity and score together for each PID:

$ for PID in 1234 2345; do
    ps -p "$PID" -o pid=,comm=
    printf 'score='
    cat "/proc/$PID/oom_score"
  done
 1234 example-service
score=512
 2345 worker
score=734

Example: here worker has the higher current score, so it is the more likely candidate under the scoring rule. That does not prove it will be picked first. Memory pressure, privileges, adjustment values, process lifetime, kernel version and the state of the whole system all matter. The score is a point-in-time observation, not a stable label glued to the executable.

Do not use a single reading to justify killing a process yourself, changing a restart policy or declaring a memory leak. Correlate it with resident memory, service logs and what the kernel actually recorded. A useful read-only check for recent OOM messages:

$ journalctl -k -b --grep='out of memory|oom-killer' --no-pager

This may need permission to read kernel logs, and its output depends on the logging setup in use. It is an investigation aid, not part of the oom_score interface.

5. Avoid changing policy while investigating

This guide only reads procfs. Writing a new value to /proc/PID/oom_score_adj changes the process's OOM preference, and that is a security and availability decision, not a diagnostic one. It can make a critical service harder to kill, or push another process further into the firing line. Do not test writes on a production service just to see whether the number moves.

If an existing runbook calls for an adjustment change, use its authorised value, service owner and rollback procedure. Record the current value before touching anything:

$ PID='1234'
$ OLD_ADJ=$(cat "/proc/$PID/oom_score_adj")
$ printf '%s\n' "$OLD_ADJ"

Recovery: after an approved change, undo it by writing the recorded value back, subject to the same permissions and service controls. If the process has already exited, do not write to a replacement process that reused the PID without first checking its command and ownership. A PID identifies a process instance, not a permanent service identity.

Common traps

Done means