How to Adjust and Display Out-of-Memory Killer Scores in Linux Using choom

When a Linux server runs out of physical RAM and swap space, the kernel invokes its Out-of-Memory (OOM) killer subsystem to prevent complete kernel panic and system lockup. The OOM killer evaluates every active process, calculates a heuristic “badness score” based on proportional memory consumption, and sends a SIGKILL signal to the process with the highest score. While this mechanism safeguards overall operating system survival, it can inadvertently terminate critical production daemons—such as SSH servers, database engines, or monitoring agents—instead of non-essential worker jobs.

Historically, systems administrators adjusted OOM protection by manually echoing integer values into virtual filesystem files located at /proc/[pid]/oom_score_adj. In modern Linux distributions, the choom utility (part of the core util-linux package) provides an official, structured command-line interface to inspect existing process OOM scores or spawn new services with designated OOM score adjustments directly.

Understanding Linux Kernel OOM Scores and Adjustments

The Linux kernel tracks two related OOM values for every running process:

• oom_score (Read-Only): A dynamic integer calculated by the kernel reflecting the likelihood of the process being killed. The higher the number (ranging from 0 to 1000), the more likely the OOM killer will select that process for immediate termination under memory exhaustion.
• oom_score_adj (Read-Write): An adjustment value configured by administrators or system managers ranging from -1000 to +1000. This score is added directly to the badness calculation before the kernel makes its eviction decision.

Setting oom_score_adj to -1000 grants complete immunity, instructing the kernel to never terminate the process via the OOM killer. Conversely, setting it to +1000 marks the process for immediate sacrifice the moment memory starvation occurs.

Querying Existing Process OOM Scores with choom

To inspect the current OOM score and adjustment applied to an active process, execute choom with the -p (PID) flag:

choom -p 1234

The utility queries the kernel procfs interface and outputs the current parameters:

pid 1234's current OOM score: 45
pid 1234's current OOM score factor: 0

If you need to locate the Process ID (PID) of a critical daemon (for example, the OpenSSH server sshd) before auditing its score:

pgrep -o sshd
choom -p $(pgrep -o sshd)

Adjusting the OOM Score of a Running Process

Modifying OOM scores requires root privileges via sudo. Use the -n flag followed by the desired integer adjustment and the target process ID:

1. Protecting a Critical Process from Termination

To make a database server or critical reverse proxy virtually immune to the OOM killer, set its adjustment factor to -1000:

sudo choom -p 2045 -n -1000

Verify that the new factor has been applied successfully:

choom -p 2045

The output confirms the factor update:

pid 2045's current OOM score: 0
pid 2045's current OOM score factor: -1000

2. Sacrificing Low-Priority Batch Tasks

If you run memory-intensive data processing scripts, web scrapers, or non-essential compile jobs, make them the preferred target for termination so production services remain untouched during unexpected memory spikes:

sudo choom -p 5678 -n 800

Spawning New Processes with Pre-Configured OOM Scores

One of the primary advantages of choom over manual procfs file writes is the ability to launch commands with custom OOM scores pre-applied from the moment of execution. This prevents race conditions where a fast-allocating job consumes memory before its procfs entry can be adjusted.

To launch a resource-heavy backup script as a disposable process:

choom -n 900 /usr/local/bin/run-heavy-backup.sh

Any child processes forked by the command automatically inherit the parent’s adjusted OOM score factor.

Persisting OOM Score Adjustments in systemd

Because process IDs change across service restarts and reboots, configuring choom manually is ideal for ad-hoc runtime adjustments or shell automation. For persistent service-level protection on modern Linux distributions, define the adjustment natively inside the systemd service unit.

Create a service override file using systemctl edit:

sudo systemctl edit nginx.service

Add the OOMScoreAdjust directive under the [Service] section:

[Service]
OOMScoreAdjust=-900

Save and exit the editor, then restart the service:

sudo systemctl restart nginx.service
choom -p $(pgrep -o nginx)

The terminal confirms that systemd applied the -900 adjustment factor during daemon instantiation.

Mastering choom and kernel OOM heuristics ensures that high-priority Linux services remain resilient against unexpected memory exhaustion events.