Docker Desktop OOMKilled Exit 137 Tracker

Threat/Impact Level: HIGH | Downtime Risk: HIGH | Time to Fix: 10–30 mins

TL;DR

• What broke: Your container's process (JVM, Node.js, Python, etc.) exceeded the 2GB Docker Desktop VM memory ceiling. The Linux OOM killer sent SIGKILL (signal 9). No graceful shutdown. No heap dump. Just dead.
• How to fix it: Set explicit mem_limit + mem_reservation in Compose, tune runtime heap flags (-Xmx, --max-old-space-size), and verify Docker Desktop's VM memory allocation is sufficient for your workload.
• Fast path: Use our Client-Side Sandbox above to auto-refactor your docker-compose.yml or docker run command — your config never leaves the browser.

$ docker run --memory=2g myapp:latest
...
Killed
$ echo $?
137

CONTAINER ID   IMAGE          COMMAND       STATUS
a3f9c1d2e8b7   myapp:latest   "java -jar"   Exited (137) 4 minutes ago

docker inspect <container_id> | grep -A5 '"OOMKilled"'
# Expected output:
# "OOMKilled": true,

How to Fix It

Step 1: Confirm Docker Desktop VM Memory Allocation

Docker Desktop → Settings → Resources → Memory. This is the hard ceiling for all containers combined. If this is set to 2GB and your container's --memory is also 2GB, you have zero headroom for the Docker daemon, other containers, or the VM OS itself.

Rule of thumb: Set the VM to at least 1.5× the sum of all container memory limits.

Step 2: Basic Fix — Set Explicit Limits in docker-compose.yml

version: '3.8'
services:
  app:
    image: myapp:latest
-   # No memory constraints set
+   mem_limit: 1g
+   mem_reservation: 512m
+   oom_kill_disable: false  # Keep true OOM visibility; never set to true in prod
    environment:
-     - JAVA_OPTS=-Xms512m
+     - JAVA_OPTS=-Xms256m -Xmx768m -XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0

mem_reservation is the soft limit (scheduling hint). mem_limit is the hard cgroup ceiling. Always set both.

Step 3: Runtime-Specific Heap Tuning

Java (JDK 11+):

- JAVA_OPTS=-Xmx2g
+ JAVA_OPTS=-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0

UseContainerSupport (default on JDK 10+) reads cgroup limits instead of host RAM. MaxRAMPercentage=75.0 leaves 25% headroom for off-heap (Metaspace, direct buffers, GC overhead).

Node.js:

- CMD ["node", "server.js"]
+ CMD ["node", "--max-old-space-size=768", "server.js"]

With a 1GB container limit, cap V8 heap at ~75% = 768MB.

Python:

Python has no built-in heap cap. Use memory-profiler or tracemalloc to identify the leak. For worker pools (Gunicorn), set --max-requests to recycle workers and prevent unbounded growth:

- CMD ["gunicorn", "app:app", "-w", "4"]
+ CMD ["gunicorn", "app:app", "-w", "4", "--max-requests", "1000", "--max-requests-jitter", "100"]

Enterprise Best Practice — Resource Limits as Code

In production Kubernetes (the real fix for Docker Desktop issues that reach prod):

apiVersion: v1
kind: Pod
spec:
  containers:
  - name: app
    image: myapp:latest
    resources:
-     # No requests or limits defined
+     requests:
+       memory: "512Mi"
+       cpu: "250m"
+     limits:
+       memory: "1Gi"
+       cpu: "1000m"

Requests = guaranteed scheduling. Limits = hard cgroup ceiling. Without requests, the scheduler places your pod on an overloaded node. Without limits, one pod can OOM the entire node.

Also configure a LimitRange at the namespace level so no one can deploy without resource constraints:

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
spec:
  limits:
  - default:
      memory: 512Mi
      cpu: 500m
    defaultRequest:
      memory: 256Mi
      cpu: 100m
    type: Container

💡 Tired of pasting proprietary infrastructure configs into public LLMs? Generic AI interfaces log your company's ARNs, connection strings, and private keys. StackEngine enforces client-side zero-trust boundaries—the sandbox above executes 100% locally in your browser. Drop your broken manifest above to redact secrets locally and synthesize deterministic patch drafts with your own API key.

(For CI/CD pipeline automation, install via npm i -g stackengine).

pip install checkov
checkov -f docker-compose.yml --check CKV_DOCKER_7,CKV_DOCKER_13
# CKV_DOCKER_7: Ensure memory is limited
# CKV_DOCKER_13: Ensure CPU is limited

- name: Lint Docker Compose resource limits
  run: checkov -f docker-compose.yml --soft-fail

# policy/deny_no_memory_limit.rego
package main

deny[msg] {
  container := input.spec.containers[_]
  not container.resources.limits.memory
  msg := sprintf("Container '%v' has no memory limit. OOMKill risk.", [container.name])
}

conftest test k8s-deployment.yaml --policy policy/

# Watch live container memory usage — run this while load testing
watch -n 1 'docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}"'

- JAVA_OPTS=-Xmx768m
+ JAVA_OPTS=-Xmx768m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/dumps/oom.hprof