You spend hours tuning your application, tweaking memory limits, and optimizing your GC cycles. Then you push it to production, and systemd nukes the process at 3 AM because it decided your service was a prime candidate for the OOM killer. It is infuriating, especially when the process was nowhere near actually exhausting system RAM.

Why systemd thinks your app is a liability

By default, systemd applies an OOMScoreAdjust to services. If you have not touched this, the kernel sees these processes as fair game when memory pressure spikes. Most engineers assume the kernel just picks the biggest consumer, but it actually calculates a score based on a variety of factors. If your service is marked with a higher-than-necessary score, you are practically handing the kernel a permission slip to kill your process first.

systemctl show your-service-name | grep OOMScoreAdjust

• The OOMScoreAdjust value ranges from -1000 to 1000.
• A negative value protects your process from being picked by the OOM killer.
• Setting it to -1000 effectively makes your service untouchable by the kernel OOM logic.

Taking back control of the OOM killer

If you are running a critical background worker or a database proxy, you need to pin this down in your unit file. Open up your override file with systemctl edit and set OOMScoreAdjust to something conservative. I usually set mine to -500 for secondary services and -1000 for critical infrastructure. Just be careful with -1000; if that process actually hits a memory leak, it will panic the kernel before it dies, which is a different kind of headache.

Check your current scores before you get paged again. Seeing a zero or a positive value on a mission-critical process is a ticking time bomb waiting for a minor memory pressure event to go off.