Supervisor Crash Loop With Exit Code 137 — Root Cause & Fix (Memory Overcommit on Debian/Ubuntu)

Community Guides
1

I’m posting this to help anyone running Home Assistant Supervised on Debian/Ubuntu who finds their Supervisor repeatedly restarting, with very little useful information in the logs.

This issue took a while to diagnose, so hopefully this saves others some pain.

Symptoms

In my case, the Supervisor kept restarting every few minutes:

hassio-supervisor.service: Deactivated successfully.
Supervisor exited with code 137
Watchdog restart after closing

Home Assistant UI also showed repeated errors like:

Connection timeout to host http://172.30.32.2/...
Client error on api core/logs request Connection timeout

Additional symptoms:

  • The Supervisor container logs appeared normal.
  • No OOM killer entries in dmesg or journalctl -k.
  • docker stats showed plenty of RAM available.
  • Supervisor restarted 5–10 times per hour.
  • Large addons (EMHASS, InfluxDB, Matter Server, FlexMeasures, etc.) would often be active when a crash occurred.

Host Memory Looked Fine… but Committed Memory Was Near the Limit

Even though I have 32 GB RAM and 24 GB+ “available”, the kernel uses a separate check:

CommitLimit:   30329384 kB
Committed_AS:  19879724 kB

If Committed_AS gets too close to the CommitLimit, new memory allocations may fail, even if there is RAM free.

This is common with Python-heavy workloads (like HA and many addons) because Python allocates large virtual memory regions.

The key detail:
The kernel can reject memory allocations without triggering an OOM kill, so it doesn’t appear in logs.

Supervisor then dies with exit code 137, which looks like an OOM kill… but isn’t.

Cause: Strict Linux Memory Overcommit Settings

On Debian/Ubuntu, these defaults can cause problems:

/proc/sys/vm/overcommit_memory = 0
/proc/sys/vm/overcommit_ratio  = 50

Mode 0 (heuristic overcommit) is conservative.
When RAM becomes fragmented or HA’s virtual memory requests spike, allocations fail silently, and the Supervisor crashes.

Fix: Relax the Overcommit Settings

Set the kernel to allow reasonable overcommit, which is safe for HA:

Apply immediately:

sudo sysctl -w vm.overcommit_memory=1
sudo sysctl -w vm.overcommit_ratio=90

Make it permanent:

sudo nano /etc/sysctl.conf

Add:

vm.overcommit_memory=1
vm.overcommit_ratio=90

Save, then reboot the host or restart HA:

sudo ha host reboot

Result

After adjusting overcommit settings:

  • Supervisor stopped crashing.
  • No more exit 137 loops.
  • API calls to addons no longer timeout.
  • System became stable even under heavy forecasting/EMHASS load.
  • No need to uninstall addons.

Why This Matters for Home Assistant Users

Home Assistant + modern addons (EMHASS, Influx, Matter Server, etc.) can make large virtual memory allocations, even if they don’t actually use that RAM.

Debian’s defaults are too conservative for these workloads.

A small tweak to vm.overcommit_memory prevents hours or days of head-scratching.

Suggested Future Improvement

It may be worth updating the HA Supervised installer docs to:

  1. Check vm.overcommit_memory and warn users.
  2. Recommend vm.overcommit_memory=1 for non-HAOS systems.
1 Like