Bug 1899162
| Summary: | RFE: let the admin configure the coredump naming | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Renaud Métrich <rmetrich> |
| Component: | systemd | Assignee: | systemd maint <systemd-maint> |
| Status: | CLOSED MIGRATED | QA Contact: | Frantisek Sumsal <fsumsal> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 8.3 | CC: | bhershbe, christoph.obexer, dtardon, fkrohn, jseunghw, kpelc, systemd-maint-list, zbyszek |
| Target Milestone: | rc | Keywords: | FutureFeature, MigratedToJIRA |
| Target Release: | 8.0 | Flags: | pm-rhel:
mirror+
|
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-09-21 11:13:15 UTC | Type: | Story |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
AFAIK hostname is available in metadata, so what you want should already be possible with coredumpctl, like this: # coredumpctl list _HOSTNAME=<hostname> This doesn't work. coredumpctl shows always Hostname as the name of the host ("vm-rhel8" in my case), even though the %h passed is "test" (name of my container).
Additionally, even though this could be a possibility, it wouldn't be convenient since admins would have to use coredumpctl commands to find out what's they are interested into.
(In reply to Renaud Métrich from comment #2) > This doesn't work. coredumpctl shows always Hostname as the name of the host > ("vm-rhel8" in my case), even though the %h passed is "test" (name of my > container). Yeah, I didn't check... The right field is COREDUMP_HOSTNAME. > Additionally, even though this could be a possibility, it wouldn't be > convenient since admins would have to use coredumpctl commands to find out > what's they are interested into. IMHO that's what they should do anyway. It allows to match all available metadata and it is more reliable than parsing coredump filenames with ad hoc globs or regexes. Indeed this works. However, this isn't "reliable" since coredumpctl bases itself on the journal, so: - if the journal rotates / vacuums, you may not have the information - if the journal is not persistent, after reboot you lose the information To summarize the discussion during the upstream meeting today: The file name is supposed to be unique and somewhat informative, but the details are not fixed API. It does include the machine id, so files from different containers are somewhat segregated. Two "official" interfaces exist: 1. the journal entry which has all the metadata 2. the extended attributes on the file $ sudo getfattr --absolute-names -d /var/lib/systemd/coredump/core.systemd.0.b07239dbd2264cc2bf9b070929ead2a7.697927.1606814763000000.zst # file: var/lib/systemd/coredump/core.systemd.0.b07239dbd2264cc2bf9b070929ead2a7.697927.1606814763000000.zst user.coredump.comm="systemd" user.coredump.exe="/usr/lib/systemd/systemd" user.coredump.gid="0" user.coredump.hostname="rawhide" user.coredump.pid="697927" user.coredump.rlimit="18446744073709551615" user.coredump.signal="11" user.coredump.timestamp="1606814763000000" user.coredump.uid="0" The attributes obviously stay behind even if the journal entry is removed. A list of all the required information for coredump analysis: * Kubernetes namespace * Pod name * Container name * Executable name * Signal * Timestamp * User * Group * Image used to run the binary * SELinux information * possibly more Putting all of these in the filename is not going to work... How about we instead get as much of that metadata as possible into an appropriate place like the system journal and/or the core dump file attributes or a file next to the dump? Pros: * less stuff to configure * fewer things to coordinate across teams * more relevant information available * defined API Cons: * None There are already metadata stored as extended attributes. Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug. This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there. Due to differences in account names between systems, some fields were not replicated. Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information. To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer. You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like: "Bugzilla Bug" = 1234567 In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information. |
Description of problem: On RHEL8, the coredump naming in /var/lib/systemd/coredump is hardcoded to "core.<COMM>.<UID>.<bootid>.<PID>.<TS>000000" This needs to be enhanced to let the admin name the coredumps as he needs to, typically adding the <HOSTNAME> (hostname or container name), which is initially available when systemd-coredump executes through kernel.core_pattern. This would help a lot analyzing OCP issues for examples. Version-Release number of selected component (if applicable): systemd-239 but also Upstream (looks like at least, from reading the code) How reproducible: ALWAYS Steps to Reproduce: 1. Create a miniroot to execute "bash" -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- # yum -y install --installroot=/tmp/test --releasever=/ bash -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- 2. Spawn a container and crash bash in the container -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- # systemd-nspawn -D /tmp/test bash Spawning container test on /tmp/test. Press ^] three times within 1s to kill container. bash-4.4# ulimit -c unlimited bash-4.4# function foo { foo } bash-4.4# foo Container test terminated by signal SEGV. -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- 3. Check the core filename (it doesn't show the container name, which would be useful) Actual results: ------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- # ls /var/lib/systemd/coredump core.bash.0.33efdaea7a3c4cce86184cbbb6c28368.2343.1605715274000000 -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- Expected results: Some custom naming based on available properties