A core dump records a process’s memory when it crashes and can help a developer investigate the failure. Linux limits and the configured dump collector determine whether and where a dump is saved.
Check the current limits
In the shell that will start the test application:
ulimit -Sc
ulimit -Hc
cat /proc/sys/kernel/core_patternThe first two commands show the soft and hard core-size limits. A soft limit of 0 disables ordinary core-file generation. A core_pattern beginning with a pipe sends dumps to a collector rather than a file in the working directory.
Enable dumps for a controlled test
Record the previous soft limit, then, if the hard limit permits it, run:
ulimit -c unlimitedStart the application from that shell and reproduce the existing fault in a test environment. This setting applies to that shell and newly started child processes, not services already running elsewhere.
A systemd service needs its own LimitCORE setting and may also be subject to collector storage limits. Have the administrator configure the intended service rather than changing every process globally.
Find the dump
On a system using systemd-coredump:
coredumpctl listIdentify the application’s matching crash before inspecting or exporting it. Other collectors use their own retrieval tools; ordinary core files follow the server’s core_pattern and permissions.
Dumps can contain credentials and personal data and may be large. Restrict access, monitor storage and share them only through an approved diagnostic route.
Restore the previous shell limit after testing. Use ulimit -c 0 if it was previously disabled.