From: Zbigniew Jędrzejewski-Szmek Date: Sun, 28 Feb 2021 10:57:43 +0000 (+0100) Subject: man: describe coredump fields X-Git-Tag: v248-rc3~92^2~16 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=9d58abfa255ac5840ba8838da3d4a9b56e44e32f;p=thirdparty%2Fsystemd.git man: describe coredump fields We save a wealth of information about the process, but this might not be immediately obvious. --- diff --git a/man/systemd-coredump.xml b/man/systemd-coredump.xml index 2d53a7a8feb..aea1cf861fa 100644 --- a/man/systemd-coredump.xml +++ b/man/systemd-coredump.xml @@ -36,7 +36,8 @@ log a summary of the event to systemd-journald.service8, including information about the process identifier, owner, the signal that killed the process, and the - stack trace if possible. It may also save the core dump for later processing. + stack trace if possible. It may also save the core dump for later processing. See the "Information about + the crashed process" section below. The behavior of a specific program upon reception of a signal is governed by a few factors which are described in detail in @@ -141,12 +142,233 @@ - Usage - Data stored in the journal can be viewed with - journalctl1 as usual. - coredumpctl1 can be - used to retrieve saved core dumps independent of their location, to display information and to process - them e.g. by passing to the GNU debugger (gdb). + Information about the crashed process + + coredumpctl1 can + be used to retrieve saved core dumps independently of their location, to display information, and to + process them e.g. by passing to the GNU debugger (gdb). + + Data stored in the journal can be also viewed with + journalctl1 as usual + (or from any other process, using the + sd-journal3 API). + The relevant messages have MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1: + $ journalctl MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1 -o verbose +… +MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1 +COREDUMP_PID=552351 +COREDUMP_UID=1000 +COREDUMP_GID=1000 +COREDUMP_SIGNAL_NAME=SIGSEGV +COREDUMP_SIGNAL=11 +COREDUMP_TIMESTAMP=1614342930000000 +COREDUMP_COMM=Web Content +COREDUMP_EXE=/usr/lib64/firefox/firefox +COREDUMP_USER_UNIT=app-gnome-firefox-552136.scope +COREDUMP_CMDLINE=/usr/lib64/firefox/firefox -contentproc -childID 5 -isForBrowser … +COREDUMP_CGROUP=/user.slice/user-1000.slice/user@1000.service/app.slice/app-….scope +COREDUMP_FILENAME=/var/lib/systemd/coredump/core.Web….552351.….zst +… + + + The following fields are saved (if known) with the journal entry + + + + COREDUMP_UID= + COREDUMP_PID= + COREDUMP_GID= + The process number (PID) and owner (UID and GID) of the crashed process. + + + + + COREDUMP_TIMESTAMP= + The time of the crash as reported by the kernel (in µs since the epoch). + + + + + COREDUMP_RLIMIT= + The core file size soft resource limit, see + getrlimit2. + + + + + COREDUMP_UNIT= + COREDUMP_SLICE= + The system unit and slice names. + + + + + COREDUMP_CGROUP= + Control group information in the format used in + /proc/self/cgroup. On systems with the unified cgroup hierarchy, this is a + single path prefixed with 0::, and multiple paths prefixed with controller numbers + on legacy systems. + + + + COREDUMP_OWNER_UID= + COREDUMP_USER_UNIT= + The numerical UID of the user owning the login session or systemd user unit of the + crashed process, and the user manager unit. Both fields are only present for user processes. + + + + + COREDUMP_SIGNAL_NAME= + COREDUMP_SIGNAL= + + The terminating signal name and numerical value. (Both are included because signal + numbers vary by architecture.) + + + + + COREDUMP_CWD= + COREDUMP_ROOT= + + The current working directory and root directory of the crashed process. + + + + + COREDUMP_OPEN_FDS= + + Information about open file descriptors, in the following format: + fd:/path/to/file +pos: ... +flags: ... +... + +fd:/path/to/file +pos: ... +flags: ... +... + + + The first line contains the file descriptor number fd and the path, + while subsequent lines show the contents of + /proc/pid/fdinfo/fd. + + + + + COREDUMP_COMM= + COREDUMP_EXE= + COREDUMP_PROC_STATUS= + COREDUMP_PROC_MAPS= + COREDUMP_PROC_LIMITS= + COREDUMP_PROC_MOUNTINFO= + COREDUMP_ENVIRON= + + Fields that map the per-process entries in the /proc/ + filesystem: /proc/pid/comm (the command name + associated with the process), /proc/pid/exe (the + filename of the executed command), /proc/pid/status + (various metadata about the process), /proc/pid/maps + (memory regions visible to the process and their access permissions), + /proc/pid/limits (the soft and hard resource limits), + /proc/pid/mountinfo (mount points in the process's + mount namespace), /proc/pid/environ + (the environemnt block of the crashed process). + + See + proc5 + for more information. + + + + COREDUMP_HOSTNAME= + + The system hostname. + + + + COREDUMP_CONTAINER_CMDLINE= + + For processes running in a container, the commandline of the process spawning the + container (the first parent process with a different mount namespace). + + + + COREDUMP= + + When the core is stored in the journal, the core image itself. + + + + + COREDUMP_FILENAME= + + When the core is stored externally, the path the the core file. + + + + + COREDUMP_TRUNCATED= + + Set to 1 when the saved coredump was truncated. (A partial core + image may still be processed by some tools, though obviously not all information is available.) + + + + + MESSAGE= + + The message generated by systemd-coredump that includes the + backtrace if it was successfully generated. When systemd-coredump is invoked with + , this field is provided by the caller. + + + + Various other fields exist in the journal entry, but pertain to the logging process, + i.e. systemd-coredump, not the crashed process. See + systemd.journal-fields7. + + + The following fields are saved (if known) with the external file listed in + COREDUMP_FILENAME= as extended attributes: + + + + user.coredump.pid + user.coredump.uid + user.coredump.gid + user.coredump.signal + user.coredump.timestamp + user.coredump.rlimit + user.coredump.hostname + user.coredump.comm + user.coredump.exe + + Those are the same as COREDUMP_PID=, + COREDUMP_UID=, COREDUMP_GID=, + COREDUMP_SIGNAL=, COREDUMP_TIMESTAMP=, + COREDUMP_RLIMIT=, COREDUMP_HOSTNAME=, + COREDUMP_COMM=, and COREDUMP_EXE=, described above. + + + + + Those can be viewed using + getfattr1. + For the core file described in the journal entry shown above: + $ getfattr --absolute-names -d /var/lib/systemd/coredump/core.Web….552351.….zst +# file: /var/lib/systemd/coredump/core.Web….552351.….zst +user.coredump.pid="552351" +user.coredump.uid="1000" +user.coredump.gid="1000" +user.coredump.signal="11" +user.coredump.timestamp="1614342930000000" +user.coredump.comm="Web Content" +user.coredump.exe="/usr/lib64/firefox/firefox" +… + +