From 2d85046af31c40b7cbd27c8971567f11f9af1bbc Mon Sep 17 00:00:00 2001 From: Adam Wright Date: Tue, 15 Sep 2026 11:14:31 -0400 Subject: [PATCH] Stop Neo4j dying on a modern host kernel MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The pinned graphdb:Release97 image ships JDK 11.0.16, whose container-metrics probe cannot read cgroup v2 as newer kernels lay it out. It throws a NullPointerException from CgroupV2Subsystem.getInstance, inside a static initialiser, so Neo4j dies with ExceptionInInitializerError before it starts and the container sits in a restart loop. Nothing in the logs names a cause a reader would connect to the host kernel. Disabling container support skips exactly that probe. The heap is pinned on the line above, so container-aware sizing was only ever going to compute a number we already override — there is nothing to lose and it is inert on older kernels. Verified on the running JVM rather than assumed: /usr/local/openjdk-11/bin/java ... -XX:-UseContainerSupport No image change: the tag is untouched and this is a runtime setting, which Neo4j's entrypoint maps from NEO4J_* into dbms.jvm.additional in neo4j.conf. Co-Authored-By: Claude Opus 5 (1M context) --- docker-compose.yml | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/docker-compose.yml b/docker-compose.yml index 713977d..4888d5f 100644 --- a/docker-compose.yml +++ b/docker-compose.yml @@ -11,6 +11,11 @@ services: - "7687:7687" # Bolt environment: - NEO4J_dbms_memory_heap_maxSize=8g + # This image ships JDK 11, whose container-metrics probe NPEs reading + # cgroup v2 on a newer host kernel — Neo4j then dies before startup with + # ExceptionInInitializerError out of CgroupV2Subsystem.getInstance. The + # heap is pinned above, so container-aware sizing buys nothing here. + - NEO4J_dbms_jvm_additional=-XX:-UseContainerSupport volumes: - neo4j_data:/data - neo4j_logs:/logs