Nymblet

SummaryARK:SE dedicated server (TheIsland, no mods) reliably stalls during startup at approximately 6.1-6.3GB RSS, before ever binding to its network ports (7777/UDP, 27015/UDP, 27020/TCP). This happens consistently across multiple different Docker images and multiple fresh installs. The same setup worked correctly on this exact hardware prior to upgrading to Unraid 7. SystemCPU: Intel i7-12700F (20 threads, max 4.9GHz) RAM: 128GB Storage: Samsung 990 Pro NVMe (cache pool), confirmed via testing that ARK data never touches the array Unraid: currently on 7.3+, using new internal SSD boot (not USB flash) Previously working on this same hardware on an Unraid 6.x release using ich777's ARKSurvivalEvolved container What currently works fine on this same hostMinecraft server (Docker) Space Engineers server (Docker) Other game server containers Images tested (both fail the same way)ghcr.io/mainfrezzer/ase-docker — Wine-based. Consistently crashes with clean FPlatformMisc::RequestExit(1) immediately after "Primal Game Data Took X seconds" log line, no crash dump, no dmesg errors. dockrbyter/arksurvivalevolved — native Linux binary. Does not crash, but RSS growth plateaus around 6.1-6.3GB and never progresses further. Confirmed via host-level /proc/<pid>/stack that the main thread is in a genuine clock_nanosleep loop (not blocked on I/O, locks, or network) — consistent with normal engine sleep/poll behavior, but never resumes real progress. One outlier run did eventually break through this plateau after ~80 minutes and continued climbing past 9GB before we stopped monitoring it; every other attempt (8+ full fresh-install attempts) has stalled indefinitely at this point. What we've ruled outvm.max_map_count — set to 1048576, confirmed applied, no change Container file descriptor limits — raised to 65536, confirmed applied, no change Docker port mappings — confirmed correct (UDP 7777/7778/27015, TCP 27020), confirmed bound at host level via docker-proxy, nothing else conflicting Docker storage — 43GB free, not a factor Unraid share cache routing — share is cacheUseCache="only", confirmed via find that no ARK files exist on array disks Disk health/thermal — 990 Pro at 50-58°C, no SMART warnings Docker cgroup limits — none set (Memory: 0, CpuQuota: 0, i.e. unlimited) CPU frequency scaling — discovered the CPU governor was set to powersave, with cores parked near 800MHz under load. Switched to performance (confirmed via /proc/cpuinfo showing 4.4-4.5GHz under load). This measurably sped up the initial climb to the plateau point but did NOT resolve the plateau itself. A non-default -ActiveEvent=WinterWonderland launch flag baked into the dockrbyter image's default startup script — removed via a custom startup script override, no change in behavior. Thread death — confirmed 21 threads alive, most in normal idle waits (futex_do_wait, epoll_wait), only the main thread is in the sleep loop. Split-lock detection — confirmed active via dmesg (x86/split lock detection: #AC: crashing the kernel on kernel split_locks and warning on user-space split_locks). Attempted to disable via both split_lock_detect=off and nosplit_lock_detect kernel boot parameters — both were rejected as "Unknown kernel command line parameters" by this kernel build. No sysfs interface exists at the documented path either. Given the actual captured kernel stack trace shows a deliberate nanosleep call rather than a split-lock trap/exception, this is likely not the actual cause, but it remains unresolved/untested in a truly-disabled state. Key evidenceKernel stack trace of the stalled main thread (captured from host via /proc/<host_pid>/stack): [<0>] hrtimer_nanosleep+0x56/0xc0 [<0>] common_nsleep+0x3a/0x40 [<0>] __do_sys_clock_nanosleep+0xbf/0xf0 [<0>] do_syscall_64+0x6b/0x1100 [<0>] entry_SYSCALL_64_after_hwframe+0x76/0x7e Question for the communityGiven this worked before an Unraid major version upgrade on identical hardware, and other CPU-intensive game servers work fine now, what changed in Unraid 6→7 (kernel version, cgroup v1→v2, split-lock handling, or something else) that could cause a legacy 32-bit-derived Unreal Engine title specifically to stall like this? Open to suggestions for kernel-level tracing (ftrace/perf) if that's the next step.