I'm running Jupyter in Docker with the jupyter/datascience-notebook:x86_64-python-3.11.6 image. On one particular VM, selecting the Python kernel immediately produces a 502 Bad Gateway, then the container exits and is restarted because of the unless-stopped policy. The R and Julia kernels work normally, and the same compose setup works on other VMs. I've already restarted the VM and checked networking, but the problem remains. The container logs only show exit code 137. Could this be related to the VM's memory limits, cgroups, architecture, kernel, or Docker runtime, and what should I check next?
3 Answers
The 502 is probably a symptom rather than the root cause: Jupyter’s gateway loses its kernel process when the container is killed. Compare this VM with a working one, especially architecture, Docker Engine version, cgroup mode, configured memory and swap, and the actual limits exposed inside the container. A fresh container or VM can help confirm whether the issue is caused by stale state, but it’s worth finding the host-level kill reason first.
You can attach to the running container and start Python manually to narrow it down. Try launching the Python executable or the kernel command from a shell, then watch `docker events`, `docker stats`, and the host logs at the same time. If Python alone causes the container to disappear, compare its installed packages and startup configuration with a working VM; if the entire container is killed, focus on OOM and cgroup enforcement rather than networking.
Exit code 137 means the process was killed with SIGKILL, and in this situation the most likely cause is an out-of-memory kill. Starting Python can use a different amount of memory than the R or Julia kernels. Check the VM’s available memory and swap, Docker/container memory limits, and the kernel logs with commands such as `dmesg -T | grep -i -E 'oom|killed process'` or `journalctl -k`. Also inspect the container’s limits with `docker inspect` and `docker stats` while starting the kernel.
The container logs only report exit code 137, and I haven’t seen an obvious resource warning yet. I’ll check the host kernel logs and the effective cgroup limits rather than relying only on Docker’s application logs.