A modded Minecraft server that dies 14 seconds after accepting connections generates about 40 crash reports in ten hours and says nothing useful after the first three. A Rust server in the same loop often writes no crash report at all, leaving a truncated log and a core dump while the supervisor keeps relaunching it. Both sequences start by stopping the loop, not reading the dump.<\/p>\n\n
This assumes shell access, root, and the ability to edit the launch command. The exit codes and filenames below are the real ones from Paper\/Forge\/Fabric and Rust’s server binary.<\/p>\n\n
A restarting server destroys evidence: each boot overwrites the latest log, rotates crash reports, and can corrupt region files mid-write. Disable automatic restart, then start once manually in the foreground.<\/p>\n\n
# systemd case\nsystemctl stop gameserver\nsystemctl disable gameserver\n# start manually, capture everything\ncd \/srv\/server && .\/start.sh 2>&1 | tee \/tmp\/tail.log<\/code><\/pre>\n\nThen reproduce twice in a row. One crash is a flaky interaction; the same crash at the same point twice is deterministic and bisectable. If it only happens with players connected, log a test client in at the same moment each run.<\/p>\n\n
Reading a JVM Crash: hs_err_pid and the Log Tail<\/h2>\n\n
The hs_err_pid*.log<\/code> file is written for a native crash, not a Java exception. Its header names the signal and the failing frame, which tells you whether you are debugging Java code or a native library a mod loaded.<\/p>\n\nhead -40 hs_err_pid*.log # signal, siginfo, problematic frame\n# SEGV \/ SIGBUS in a .so -> native mod code\n# EXCEPTION_ACCESS_VIOLATION + 'Problematic frame: C [libc.so]' -> suspect JNI\n# OutOfMemoryError in a thread dump -> heap, not a crash<\/code><\/pre>\n\nSIGSEGV with the problematic frame in a .so<\/code> under mods\/<\/code> or libraries\/<\/code> is a native library bug, usually a build compiled against a different glibc or CPU baseline. SIGBUS in a memory-mapped file points at region files, and the fix is a restore, not a mod removal.<\/p>\n\nWith no hs_err<\/code> file the JVM caught an exception and exited cleanly, which is a Java-level problem: read the log for the first Caused by:<\/code> chain, not the last. The final exception is usually a shutdown handler failing after the real fault.<\/p>\n\nIsolating the Offending Mod by Bisection<\/h2>\n\n
With a deterministic reproduction, bisect the mod list. Moving half the jars out of mods\/<\/code> and booting takes two minutes; a 180-mod pack resolves in eight rounds.<\/p>\n\nmkdir -p \/tmp\/modstash\nls mods > \/tmp\/allmods.txt # record the full list first\n# move second half out\nsed -n '91,180p' \/tmp\/allmods.txt | xargs -I{} mv mods\/{} \/tmp\/modstash\/<\/code><\/pre>\n\nTwo caveats break naive bisection. Removing a library mod others depend on produces its own missing-dependency crash at load, so check the signature matches the original. Some packs fail only on a combination, so bisection converges on a pair \u2014 if the two halves give different crashes, look in the overlap.<\/p>\n\n
Rust has no loadable mod list in that sense, so the equivalent is plugin bisection under oxide\/plugins\/<\/code>. The failure usually surfaces as a .NET exception with the plugin name in the trace \u2014 same method, smaller search space.<\/p>\n\nMemory Settings That Actually Cause Crash Loops<\/h2>\n\n
Many ‘mod crashes’ are heap configuration mistakes. Three account for most cases, and all produce a loop that looks like a mod fault because the exception fires inside mod code.<\/p>\n\n
First, -Xmx<\/code> set close to physical RAM. A 16 GB box with -Xmx14G<\/code> leaves 2 GB for the OS, metaspace, thread stacks, direct buffers, and page cache. The OOM killer takes the process and there is no hs_err<\/code> because the kernel did the killing. If dmesg | grep -i 'killed process'<\/code> shows it, the fix is -Xmx10G<\/code>, not a mod removal.<\/p>\n\nSecond, heap versus off-heap. Chunk generators and Netty allocate direct buffers outside the heap, so a server at 60% heap usage can still die of native exhaustion at 13 GB RSS. If RSS climbs while heap stays flat, the limit is off-heap and -XX:MaxDirectMemorySize<\/code> needs an explicit value.<\/p>\n\nThird, GC pressure misread as a crash. An 8 GB heap running 200 mods at 60 players spends 25% of its time in GC and logs ‘tick took 4500ms’ instead of crashing, until it degrades into an OOM. G1 with a 200\u2013400 ms pause target is the practical default; older collectors produce pause spikes that look like network problems.<\/p>\n\n