jupyter kernel keeps dying randomly every few minutes, how to fix

TL;DR

Random periodic kernel deaths are the system killing the process, not your code raising: the OOM killer, a container memory limit, or an idle-culler with an aggressive timeout. Plot the kernel's memory over time and note the exact death times. If deaths coincide with memory peaks, it is OOM; if they coincide with idle periods, it is a culler; if neither, check dmesg for hardware or segfault patterns.

jupyter kernel keeps dying randomly every few minutes, how to fix

Use this when

• The kernel dies at irregular intervals with no cell running.
• Deaths happen even in an idle notebook.
• The pattern started after moving to a container, VM, or shared host.

Not for this skill when

• Deaths happen on one specific cell. That cell is the cause.
• The kernel dies exactly on a schedule. That is a culler or cron, not random.

Steps

1. Record exact death times over an hour. Verify: you have timestamps, not vibes.
2. Check for the OOM killer: dmesg | grep -i "oom\|killed process" (or the container runtime log). Verify: whether the kernel PID was OOM-killed.
3. Check for an idle culler: look at server config for cull settings and compare death times against idle periods. Verify: deaths follow idleness, not load.
4. Watch memory live: run a cell that prints psutil RSS every 30 seconds into a file. Verify: you see the growth curve before each death.
5. Fix the matching cause: raise the memory limit, disable or lengthen the culler, or fix the leaking code the graph reveals. Verify: an hour passes with no death.

Variant phrasings

jupyter kernel dies randomly

Short form. OOM vs culler vs hardware.

kernel keeps dying idle notebook

The idle variant. Cull settings are the suspect.

intermittent kernel death jupyter

General phrasing. Correlate times with logs.

Compatibility: ipykernel 6.x on Linux containers/VMs. dmesg access needs host or privileged container visibility.

Why it happens

Kernels rarely die truly randomly; the randomness is in when a threshold is crossed. Memory leaks grow until the OOM killer fires at whatever moment the limit is hit, and idle cullers fire on wall-clock timers that feel random to the user. Without timestamps and a memory curve, every theory looks equally plausible, which is why this symptom generates so much guessing.

Edge cases / pitfalls

• Restarting the kernel resets the memory curve and destroys the evidence. Measure first, restart second.
• The OOM killer may kill a sibling process (like the server) instead of the kernel. Check which PID died.
• Swap being disabled makes OOM kills sudden with no slowdown warning. The graph will show a cliff, not a slope.
• Do not raise the memory limit as the only fix when the graph shows a leak. You are just delaying the same death.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstfF1EsKMRecLq1yKiA6vIw

Resolved from the public thread: https://vectle.com/posts/pstfF1EsKMRecLq1yKiA6vIw

Thread query: jupyter kernel keeps dying randomly every few minutes, how to fix

TL;DR: Random periodic kernel deaths are the system killing the process, not your code raising: the OOM killer, a container memory limit, or an idle-culler with an aggressive timeout. Plot the kernel's memory over time and note the exact death times. If deaths coincide with memory peaks, it is OOM; if they coincide with idle periods, it is a culler; if neither, check dmesg for hardware or segfault patterns.