MongoDB Failed With Result Core Dump: How to Diagnose and Fix mongod Crashes

The systemd message mongod.service: Failed with result 'core-dump' means the MongoDB server process was terminated by a fatal signal and the kernel produced a core dump instead of allowing a clean shutdown. This is fundamentally different from a configuration error: mongod did not refuse to start, it started and then crashed hard. A core dump is a snapshot of a process's memory written at the moment it received an unrecoverable signal such as SIGILL, SIGSEGV, or SIGABRT. That distinction matters, because it immediately rules out most of the things people try first. Editing mongod.conf, changing the port, or reinstalling the package almost never fixes a core dump. The signal number in the systemd status line tells you what actually happened, and on modern servers one cause dominates all others: a CPU that does not support the AVX instruction set required by MongoDB 5.0 and later.

Quick Answer: A core dump means mongod was killed by a fatal signal, not a config error. Check systemctl status mongod for the signal: status 4/ILL almost always means the CPU lacks AVX support required by MongoDB 5.0+. Other common causes are corrupt WiredTiger data files, wrong dbpath ownership, and a full disk.

Getting Expert Help With MongoDB Reliability and Server Hardening

A crashing database is rarely just a database problem. It usually exposes a gap in how the environment was provisioned, how backups were verified, or how the virtualisation layer was configured, which is why crash recovery and infrastructure review belong together. WebPeak's engineers handle production MongoDB deployments across virtualised and cloud hosts and approach a core dump as a root-cause investigation rather than a restart loop. Their back-end web development specialists work directly with WiredTiger recovery, replica set failover, and driver-level retry logic, and their website maintenance and support team monitors mongod health so a silent crash does not become an outage. You can review the full range of what they do at webpeak.org.

How Do You Find the Real Cause Instead of Guessing?

Start with the signal, not the config file. Run systemctl status mongod and read the Main process exited line carefully, because the code after status= is the whole diagnosis. status=4/ILL is SIGILL, an illegal instruction, meaning the CPU was asked to execute an instruction it does not implement. status=11/SEGV is a segmentation fault, which points at memory or corrupted on-disk structures. status=6/ABRT is an assertion failure inside mongod, usually a data integrity check. If instead you see code=killed, signal=KILL with exit code 137, that is not a core dump at all but the Linux OOM killer reclaiming memory.

Next, gather the three log sources that matter in a single pass: sudo journalctl -u mongod -n 200 --no-pager for the systemd view, sudo tail -n 200 /var/log/mongodb/mongod.log for MongoDB's own account of what it was doing, and sudo dmesg -T | tail -n 50 for kernel-level evidence of OOM kills or hardware faults. The single most useful confirmation test for the AVX case takes one command: lscpu | grep -o avx. Empty output on a machine running MongoDB 5.0 or newer is your answer, and no amount of reinstalling will change it.

What Are the Fixes for Each Cause?

Match the fix to the signal you identified. Work through these in order rather than applying all of them at once, so you know which change actually resolved the crash:

1. Missing AVX (status=4/ILL): MongoDB requires AVX from version 5.0 onward. Either move to hardware or a cloud instance type with AVX, enable host CPU passthrough in your hypervisor (in Proxmox set CPU type to host, in VirtualBox and older ESXi builds AVX may be masked by default), or install MongoDB 4.4, which does not require AVX.
2. Wrong ownership on dbpath: Run sudo chown -R mongodb:mongodb /var/lib/mongodb /var/log/mongodb. This is the usual aftermath of restoring files as root or copying a data directory between servers.
3. Corrupt WiredTiger files (SEGV or ABRT with WiredTiger lines in mongod.log): Take a filesystem-level copy of the data directory first, then attempt sudo -u mongodb mongod --dbpath /var/lib/mongodb --repair. Repair can discard unrecoverable documents, so the backup copy is not optional.
4. Disk full: Check with df -h. WiredTiger cannot checkpoint without free space, and a full volume produces abrupt fatal exits that look like corruption.
5. Downgraded binaries on newer data files: If you installed an older MongoDB version over an existing dbpath, mongod aborts rather than risk the data. Reinstall the matching major version or restore from a dump.
6. Resource limits and THP: Confirm the systemd unit allows enough open files (LimitNOFILE=64000) and disable transparent huge pages, which MongoDB documents as a source of degraded and unstable behaviour.

Which systemd Signature Points to Which Problem?

Because the log wording is consistent across distributions, you can triage the vast majority of mongod crashes from the status line alone. The table below maps what systemd prints to the underlying condition and the first action to take.

systemd signature	What it means	First action
status=4/ILL, result core-dump	Illegal instruction, CPU lacks AVX	Check lscpu for avx; use MongoDB 4.4 or AVX-capable hardware
status=11/SEGV, result core-dump	Segmentation fault, often corrupt data files	Back up dbpath, then run mongod --repair
status=6/ABRT, result core-dump	Internal assertion or integrity check failed	Read mongod.log for the assertion text before acting
status=14, result exit-code	Startup aborted, not a crash	Fix dbpath permissions, port conflict, or config syntax
code=killed, signal=KILL, exit 137	OOM killer terminated mongod	Add RAM or swap, cap WiredTiger cacheSizeGB

What Does Experience Teach About Preventing These Crashes?

MongoDB's official documentation states plainly that version 5.0 and later require a CPU with AVX support, and that requirement is the reason this error spiked so sharply among self-hosted users: an upgrade path that worked fine for years suddenly fails on older Xeon and Opteron hardware, on budget VPS plans running dated host CPUs, and inside hypervisors that mask CPU flags from guests by default. MongoDB also documents 4.4 as the last release without that requirement, which is why downgrading is a legitimate short-term answer rather than a hack. In practice, a virtual machine created from a default template is more likely to hide AVX than the host is to lack it, so checking the hypervisor CPU model before blaming the hardware saves a wasted migration.

The original insight most guides miss is that a core dump is a symptom of missing operational guardrails, not just a bad afternoon. Teams that recover fastest share three habits: they alert on mongod.service state changes rather than only on connection failures, they keep a verified restore path so --repair is never their only option, and they treat CPU feature requirements as an explicit prerequisite in provisioning documentation. Reading the assertion text in mongod.log instead of the systemd summary is also consistently more informative, because MongoDB records the collection or index it was touching when it aborted, which frequently identifies a single damaged file rather than a broken database. If a crash exposed a wider gap in monitoring, backup verification, or host configuration, that is genuinely a security and resilience engineering concern as much as a database one, and it deserves the same rigour as application code.

Key Takeaways

• A core dump means mongod was killed by a fatal signal, so config edits and reinstalls rarely help.
• status=4/ILL is the signature of a CPU without AVX, which MongoDB 5.0 and later require.
• MongoDB 4.4 is the last major version that runs without AVX, making it a valid fallback on older hardware.
• Always copy the data directory before running mongod --repair, because repair can discard unrecoverable documents.
• Exit code 137 with signal=KILL is the OOM killer, not corruption, and is solved with memory or a WiredTiger cache limit.

Frequently Asked Questions

What does mongod.service failed with result core-dump actually mean?

It means the MongoDB process received a fatal signal and the kernel dumped its memory rather than letting it shut down cleanly. The service did not fail to start, it crashed while running. The signal code in systemctl status mongod identifies the specific fault.

Why does MongoDB crash immediately after installation on my old server?

Most likely your CPU does not support AVX, which MongoDB requires from version 5.0 onward. The process starts, hits an unsupported instruction, and dies with SIGILL. Confirm with lscpu | grep avx, then either use AVX-capable hardware or install MongoDB 4.4.

How do I check whether my CPU supports AVX?

Run lscpu | grep -o avx or grep -o avx /proc/cpuinfo | head -1. If the command returns nothing, AVX is unavailable or masked by your hypervisor. On virtual machines, set the guest CPU type to host passthrough so the flag is exposed to the guest.

Is running mongod --repair safe on production data?

Repair is a last resort, not a routine fix. It rebuilds indexes and can permanently drop documents it cannot read. Always take a filesystem copy of the entire data directory first, and prefer restoring from a verified backup or resyncing from a healthy replica set member.

Can not enough RAM cause a MongoDB core dump?

Low memory usually produces an OOM kill rather than a true core dump, shown as signal=KILL with exit code 137 and a matching entry in dmesg. Fix it by adding memory or swap, or by setting storage.wiredTiger.engineConfig.cacheSizeGB to a conservative value.

Conclusion

The one decision that resolves this issue fastest is refusing to guess: read the signal code in systemctl status mongod and let it choose your fix, because SIGILL, SEGV, and an OOM kill require three completely different responses. Check AVX support first on any self-hosted or virtualised server, since that single prerequisite accounts for the majority of sudden mongod core dumps after an upgrade. Once the service is stable, add state-change alerting and test a real restore, so the next crash becomes a routine recovery instead of an emergency. Getting there is straightforward engineering discipline, and it is what separates a database that survives incidents from one that merely runs.