A systemd service has just crashed and you already have its name, but the log is not enough to identify the process that actually failed. Before restarting the unit or modifying its configuration, note the time of the incident, then search for the associated core dump using coredumpctl.
Before the first command, check the following points:
- the concerned systemd unit is known;
- the approximate time of the crash is available;
- you have the necessary rights to read the log and the dump;
- the file must not leave the machine nor be shared as is.
Start with the time and the process of the crash
Display the available entries without opening a pager:
coredumpctl --no-pager listThe command notably displays TIME, the PID, the user, the signal, the storage status, and the executable path. Remember the line whose time corresponds to the service stop. The PID allows you to avoid confusion between two processes with similar names.
The COREFILE column indicates the possible next steps. present signals an accessible file, while journal indicates content stored in the log. missing means that the entry still exists even though the file has disappeared. A value of none, error, or truncated limits the analysis. The log can thus keep track of a crash after the associated file has been deleted, notably in /var/lib/systemd/coredump.
Do not launch coredumpctl debug yet. The command opens a debugger on the selected dump without automatically explaining the cause or restoring the service to a working state.
Read a targeted dump with coredumpctl info
Once you have noted the PID, request the metadata for this entry:
coredumpctl info <PID>If the list instead provides a usable executable path, target that path:
coredumpctl info /usr/bin/executable-nameReplace the values between angled brackets with those from your output. The command displays the PID, the signal, the timestamp, the command line, the executable, and the size occupied. It may also reveal the systemd unit via the Unit field, as well as the storage path and its status.
The Unit field links the dump to the systemd diagnosis. Check that it corresponds to the crashed service and that the time aligns with the observed symptom. A PID alone is not sufficient if multiple executions have occurred in quick succession. A user without full access to the log may also only see part of the entries, often those of their own processes.
Cross-reference the dump with the unit’s log
After retrieving the exact name of the unit and the crash time, read a short window around that moment:
journalctl -u unit-name --since "10 minutes ago" --until "now"For an older incident, replace the relative window with two timestamps that frame the one displayed by coredumpctl info. The log should then show the stopping of the process, the exit code or the signal, the restart attempts, and the messages written just before the crash.
The failure counter does not provide the cause. If the unit is still marked failed, the guide dedicated to systemctl reset-failed reminds of the difference between the state tracked by systemd and the error that appears in the log. To read the events preceding the crash, your service journal with journalctl provides suitable filters.
If the unit’s log is not sufficient and the messages mention a driver, disk, or the kernel, also check the kernel messages with dmesg. This check serves to confirm a low-level incident, without replacing the reading of the service.
Keep core dumps within a controlled perimeter
A core dump may contain a portion of the process’s memory at the time of the crash. Depending on the application, this memory may include data being processed, identifiers, tokens, or fragments of configuration. Treat the file as sensitive data, even if its name resembles a simple technical artifact.
The official coredumpctl documentation distinguishes between reading metadata, extracting with dump, and opening a debugger with debug. On a production machine, stop after info until the analysis perimeter, access rights, and working storage are validated. An improvised export or sending the file to a third party may expose much more than the name of the failing service.
If coredumpctl is absent or if the list remains empty, what follows depends on the distribution and its systemd-coredump collection policy. Check this policy with your system’s documentation before making changes to production.