Bug 410631
Summary: | add full executable path .note to corefile | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Andrew Cagney <cagney> |
Component: | kernel | Assignee: | Red Hat Kernel Manager <kernel-mgr> |
Status: | CLOSED DUPLICATE | QA Contact: | Martin Jenner <mjenner> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 5.1 | CC: | ebachalo, jan.kratochvil, nhorman, pmuldoon |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-11-17 17:23:21 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 173278 |
Description
Andrew Cagney
2007-12-04 16:42:58 UTC
Adding another frysk bug, caused by the limitation. You shouldn't need this in RHEL5 after 5.2. WE've backported the core_pattern features from upstream, which allow you to pipe a core to an executable. Using this feature you can extract the pid of the crashing process, and find the full pathname by doing a readlink on /proc/<pid>/exe (In reply to comment #2) > You shouldn't need this in RHEL5 after 5.2. WE've backported the core_pattern > features from upstream, which allow you to pipe a core to an executable. Using > this feature you can extract the pid of the crashing process, and find the full > pathname by doing a readlink on /proc/<pid>/exe Is there a reference for the core_pattern feature? Our problem is determining the original executable's name so that, for instance, we can "pipe" to it. The 80 character limit causes this path to be truncated, and hence the exact executable to be unknown. There is s reference, if you get the upstream git tree, and look in Documentation/sysctl/kernel.txt, the details of core_pattern are listed there BTW it is unfortunate if RH is going to depend on core_pattern. I cannot find his citation but IIRC Roland McGrath was proposing the whole build-id F8+ feature than some userland program hook at the core dumping time to be able to dump cores even with very broken system (low on memory, userland execution broken etc.). With the dependency on a userland core files dumper the build-id feature could be simplified a lot (IMO in fact it would not be needed at all). Please disregard my previous Comment 5. Roland has nothing against core_pattern, the reasons against `rpm -qf' at the core_pattern dumping time are: On Thu, 14 Aug 2008 22:41:08 +0200, Roland McGrath wrote: > This is more complicated, has more dependencies and is more error-prone. > You'd want it to record the exact package version, not just a name. Then > you'd want to verify that it really was the official unmodified version of > that file. So you're checking the file's md5sum--and worse, the full rpm -V > work including prelink -y--but that is so slow, you'd surely save some > cache indexed by dev+inode+ctime. That is no small amount of hair, just to > get back to the level of reliability of a plain simple core dump with ELF > headers (assuming distro-level sanity ensures build IDs are properly unique). > > No fancy new plans obviate build ID at all. It complements them, > and gives a great leg up for implementing many such things. The feature core_pattern in RHEL5.3 will address this issue: Tue Sep 09 2008 Don Zickus [2.6.18-110.el5] [misc] pipe support to /proc/sys/net/core_pattern (Neil Horman ) [410871] per developer: WE've backported the core_pattern features from upstream, which allow you to pipe a core to an executable. Using this feature you can extract the pid of the crashing process, and find the full pathname by doing a readlink on /proc/<pid>/exe *** This bug has been marked as a duplicate of bug 410871 *** Besides implemented build-id it is now also implemented by ABRT and its corefile associated files: /var/spool/abrt/ccpp-*/executable |