Activity

1. jieguolove

   added

   bugSomething isn't workingSomething isn't working

   on Jun 29, 2026
2. dosubot commented on Jun 29, 2026

   

   dosubotBot

   on Jun 29, 2026 – with DosuBot

   More actions

   This error (pthread_create failed (EPERM)) is not a HugeGraph-specific bug — it's a Docker host-level issue where the container is being denied permission to create threads. The EPERM (Operation not permitted) error typically comes from one of these causes:

   1. Docker's default seccomp profile blocking the clone syscall on certain kernel/Docker version combinations. Try running with --security-opt seccomp=unconfined:

      docker run -itd --name=hugegraph --security-opt seccomp=unconfined -p 8080:8080 hugegraph/hugegraph:1.7.0

   2. Insufficient ulimits for processes/threads. You can raise them explicitly:

      docker run -itd --name=hugegraph --ulimit nproc=65535:65535 -p 8080:8080 hugegraph/hugegraph:1.7.0

   3. SELinux or AppArmor policies on your host (lnpg) blocking thread creation inside the container. If SELinux is enforcing, try:

      docker run -itd --name=hugegraph --security-opt label=disable -p 8080:8080 hugegraph/hugegraph:1.7.0

   4. cgroup PID limits — some systems set a low pids.max in the container's cgroup. Check with docker run --pids-limit=-1 ....

   The HugeGraph Docker image uses standard container-aware JVM settings (-XX:+UseContainerSupport -XX:MaxRAMPercentage=50) and does not require any special security profiles [1]. The issue is on your host's security/resource configuration side rather than in HugeGraph itself.

   I'd suggest trying option 1 (--security-opt seccomp=unconfined) first as it's the most common fix for this specific error.

   To reply, just mention @dosu.

   ---

   Docs are dead. Just use Dosu.

   
3. jieguolove commented on Jun 29, 2026

   

   jieguolove

   on Jun 29, 2026

   Author

   More actions

   (base) [root@lnpg ~]# docker run -itd --name=hugegraph -p 8080:8080 --memory=8g --security-opt seccomp=unconfined -e PRELOAD=true -e JAVA_OPTS="-Xms2048m -Xmx2048m -XX:+UseG1GC" hugegraph/hugegraph:1.7.0
   bf42813a9146eee0be3eba171ed8c218429d117f745728eb185881f647c7d759
   (base) [root@lnpg ~]# docker logs -f hugegraph
   [hugegraph-server-entrypoint] init hugegraph with non-auth mode
   Initializing HugeGraph Store...
   2026-06-29 00:52:05 [main] [WARN] o.a.h.c.HugeConfig - The config option 'arthas.telnet_port' is redundant, please ensure it has been registered
   2026-06-29 00:52:05 [main] [WARN] o.a.h.c.HugeConfig - The config option 'arthas.http_port' is redundant, please ensure it has been registered
   2026-06-29 00:52:05 [main] [WARN] o.a.h.c.HugeConfig - The config option 'arthas.disabled_commands' is redundant, please ensure it has been registered
   2026-06-29 00:52:05 [main] [INFO] o.a.h.u.ConfigUtil - Scanning option 'graphs' directory './conf/graphs'
   2026-06-29 00:52:05 [main] [INFO] o.a.h.c.InitStore - Init graph with config file: /hugegraph-server/conf/graphs/hugegraph.properties
   2026-06-29 00:52:05 [db-open-1] [INFO] o.a.h.b.s.r.RocksDBStore - Opening RocksDB with data path: rocksdb-data/data/m
   2026-06-29 00:52:05 [db-open-1] [INFO] o.a.h.b.s.r.RocksDBStore - Failed to open RocksDB 'rocksdb-data/data/m' with database 'default/hugegraph', try to init CF later
   2026-06-29 00:52:05 [main] [INFO] o.a.h.b.c.CacheManager - Init RamCache for 'schema-id-DEFAULT-hugegraph' with capacity 10000
   2026-06-29 00:52:05 [main] [INFO] o.a.h.b.c.CacheManager - Init RamCache for 'schema-name-DEFAULT-hugegraph' with capacity 10000
   2026-06-29 00:52:05 [db-open-1] [INFO] o.a.h.b.s.r.RocksDBStore - Opening RocksDB with data path: rocksdb-data/data/s
   main dict load finished, time elapsed 734 ms
   model load finished, time elapsed 37 ms.
   2026-06-29 00:52:06 [db-open-1] [INFO] o.a.h.b.s.r.RocksDBStore - Opening RocksDB with data path: rocksdb-data/data/g
   2026-06-29 00:52:06 [main] [INFO] o.c.o.l.Uns - OHC using JNA OS native malloc/free
   2026-06-29 00:52:06 [main] [INFO] o.a.h.b.c.CacheManager - Init LevelCache for 'vertex-DEFAULT-hugegraph' with capacity 10000:10000000
   2026-06-29 00:52:06 [main] [INFO] o.a.h.b.c.CacheManager - Init LevelCache for 'edge-DEFAULT-hugegraph' with capacity 1000:1000000
   2026-06-29 00:52:06 [main] [INFO] o.a.h.t.TaskManager - Use local as the scheduler of graph (hugegraph)
   2026-06-29 00:52:06 [main] [INFO] o.a.h.b.c.CacheManager - Init RamCache for 'users-DEFAULT-hugegraph' with capacity 10240
   2026-06-29 00:52:06 [main] [INFO] o.a.h.b.c.CacheManager - Init RamCache for 'users_pwd-DEFAULT-hugegraph' with capacity 10240
   2026-06-29 00:52:06 [main] [INFO] o.a.h.b.c.CacheManager - Init RamCache for 'token-DEFAULT-hugegraph' with capacity 10240
   2026-06-29 00:52:06 [main] [INFO] o.a.h.b.s.r.RocksDBStore - Write down the backend version: 1.11
   2026-06-29 00:52:06 [main] [INFO] o.a.h.StandardHugeGraph - Graph 'DEFAULT-hugegraph' has been initialized
   2026-06-29 00:52:06 [main] [WARN] o.a.h.c.HugeConfig - The config option 'arthas.telnet_port' is redundant, please ensure it has been registered
   2026-06-29 00:52:06 [main] [WARN] o.a.h.c.HugeConfig - The config option 'arthas.http_port' is redundant, please ensure it has been registered
   2026-06-29 00:52:06 [main] [WARN] o.a.h.c.HugeConfig - The config option 'arthas.disabled_commands' is redundant, please ensure it has been registered
   2026-06-29 00:52:06 [main] [INFO] o.a.h.StandardHugeGraph - Close graph standardhugegraph[DEFAULT-hugegraph]
   2026-06-29 00:52:06 [db-open-1] [INFO] o.a.h.b.s.r.RocksDBStore - Opening RocksDB with data path: rocksdb-data/data/m
   2026-06-29 00:52:06 [db-open-1] [INFO] o.a.h.b.s.r.RocksDBStore - Opening RocksDB with data path: rocksdb-data/data/s
   2026-06-29 00:52:06 [db-open-1] [INFO] o.a.h.b.s.r.RocksDBStore - Opening RocksDB with data path: rocksdb-data/data/g
   2026-06-29 00:52:06 [main] [INFO] o.a.h.HugeFactory - HugeFactory shutdown
   2026-06-29 00:52:06 [hugegraph-shutdown] [INFO] o.a.h.HugeFactory - HugeGraph is shutting down
   Initialization finished.
   Starting HugeGraphServer in daemon mode...
   Connecting to HugeGraphServer (http://0.0.0.0:8080/graphs)....OK
   Started [pid 1079]
   Waiting for partition assignment...

   
4. bitflicker64 commented on Jun 29, 2026

   

   bitflicker64

   on Jun 29, 2026

   Contributor

   More actions

   @dosu just to confirm — this is not a HugeGraph code issue. The pthread_create failed (EPERM) error is caused by the Docker host's seccomp profile blocking the clone syscall that the JVM needs to spawn GC threads at startup. HugeGraph's Docker image is fine; the same image works on most hosts. The fix is host-side: running with --security-opt seccomp=unconfined lifts the restriction and lets the JVM create threads normally. Can you confirm this diagnosis and whether there's anything we should add to the docs or image to surface a clearer error message for users hitting this?
5. dosubot commented on Jun 29, 2026

   

   dosubotBot

   on Jun 29, 2026 – with DosuBot

   More actions

   You've reached the limit of 20 interactions per month. Your usage will reset on 2026-07-01. If you'd like to use Dosu before then, upgrade to a pro account.

   To reply, just mention @dosu.

   ---

   Share context across your team and agents. Try Dosu.

   
6. bitflicker64 commented on Jun 29, 2026

   

   bitflicker64

   on Jun 29, 2026

   Contributor

   More actions

   Not a HugeGraph bug. The pthread_create failed (EPERM) is the Docker host's seccomp profile blocking the clone syscall the JVM needs to spawn GC threads at startup. The image uses standard container-aware JVM flags (-XX:+UseContainerSupport -XX:MaxRAMPercentage=50) on eclipse-temurin:11-jre-jammy, nothing here causing it.

   Fix is host-side:

   docker run -itd --name=hugegraph -p 8080:8080 --security-opt seccomp=unconfined hugegraph/hugegraph:1.7.0

   @jieguolove your second run with seccomp=unconfined came up fine (server started on 8080), so that confirms it.

   Two things we could improve for next time someone hits this:

   1. The Docker README has no troubleshooting section for startup failures. Adding one with the seccomp fix would save people a lot of head-scratching.

   2. The entrypoint could grep hs_err_pid*.log for the EPERM pattern after a failed startup and print a hint about the seccomp flag. Small change, saves real debugging time.

   can put up a pr but would increase code complications..
7. pallavithegod commented on Oct 16, 2026

   

   pallavithegod

   on Oct 16, 2026

   Contributor

   More actions

   I've submitted the startup diagnostic improvements in #3360, and the latest review has no blocking findings. Could a maintainer assign this issue to me while I follow the PR through review?
8. imbajin

   closed this as completedin #3360on Oct 21, 2026