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.

$ 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

• No row from ps. The process may have exited, or the PID is wrong.
• Short-lived process. Re-run the ps check immediately before the score read, so a restart cannot slip a different process under the same variable.
• Permission denied. Procfs permissions, container boundaries or a security policy can all restrict access to another user's process. Confirm the PID and ownership first.

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

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

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.

$ 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

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"

Common traps

• Missing file. Check that /proc is mounted and the target process still exists; a container may expose a restricted process view.
• Permission denied. Check process ownership and the host's procfs and security policy before reaching for sudo. Root is not a substitute for finding the right process.
• Changing number. Read the score and adjustment again with the same PID, then check memory use and recent OOM events. Variation is expected as process state changes.
• Unexpected confidence. A lower score is not immunity, and a higher score is not a certain kill.
• Old documentation. The installed page notes that fork rate, CPU or run time, nice value and direct hardware access were additional factors before Linux 2.6.36. Do not present those historical factors as the current formula on a modern kernel.