RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 614303 - ssh dump doesn't work with 'cp' core_collector
Summary: ssh dump doesn't work with 'cp' core_collector
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kexec-tools
Version: 6.0
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Neil Horman
QA Contact: Chao Ye
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-07-14 04:34 UTC by Cong Wang
Modified: 2013-09-30 02:18 UTC (History)
8 users (show)

Fixed In Version: kexec-tools-2_0_0-117_el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-11-11 14:45:16 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
patch to ignore core_collector if its not makedumpfile (1.14 KB, patch)
2010-07-14 15:09 UTC, Neil Horman 		no flags Details | Diff
View All

Description Cong Wang 2010-07-14 04:34:46 UTC 
Description of problem:

Quote from Neil Horman:
I notice that setting CORE_COLLECTOR to cp doesn't work with ssh targets, since it expects CORE_COLLECTOR to copy data to stdout.  Might want to look at doing something about that (although I'm not sure what quite yet).
Comment 2 Neil Horman 2010-07-14 15:09:33 UTC 
Created attachment 431807 [details]
patch to ignore core_collector if its not makedumpfile

Amerigo, can you please try this patch for me (I don't have a free system to test on at the moemnt).  It basically just ignores core_collector if its not makedumpfile, which I think is the only sane thing to do when using scp.
Comment 3 Cong Wang 2010-07-15 04:54:04 UTC 
It works, but I replaced the 'grep' with bash variable substitution, I think this is simpler. I will check in the modified version of your patch. Thanks.
Comment 4 Sarina Canelake 2010-07-15 21:41:01 UTC 
(In reply to comment #2)
> Created an attachment (id=431807) [details]
> patch to ignore core_collector if its not makedumpfile
> 
> Amerigo, can you please try this patch for me (I don't have a free system to
> test on at the moemnt).  It basically just ignores core_collector if its not
> makedumpfile, which I think is the only sane thing to do when using scp.    

Hi,
I am wondering if this is the best solution. I invoke a custom script as my core_collector, to account for the different ways of invoking makedumpfile on baremetal vs. dom0 kernels (I provide myself some options and extensions on top of the basic makedumpfile). My script does call makedumpfile and will write to stdout in this place but the name of my script is obviously not makedumpfile. So I worry that grepping for makedumpfile straight in the core_collector name is too restrictive and could affect people calling their own scripts.

I will try to think of a better way to get around this. I guess I can rename my script such that "makedumpfile" is contained within it, but that does become bulky and requires updating in many locations where it is being used. 

Anyways just a thought. I don't know if other users would be running a custom script as their core_collector.
Comment 5 Cong Wang 2010-07-16 06:28:40 UTC 
(In reply to comment #4)
> I am wondering if this is the best solution. I invoke a custom script as my
> core_collector, to account for the different ways of invoking makedumpfile on
> baremetal vs. dom0 kernels (I provide myself some options and extensions on top
> of the basic makedumpfile). My script does call makedumpfile and will write to
> stdout in this place but the name of my script is obviously not makedumpfile.
> So I worry that grepping for makedumpfile straight in the core_collector name
> is too restrictive and could affect people calling their own scripts.
> 

This is reasonable, but I am not sure. The interface of CORE_COLLECTOR is pretty limited, it requires sometimes to copy to stdout (then it only accepts one argument), sometimes to copy to another core file (then it accepts two arguments).

The best solution I can think of is to invent different CORE_COLLECTOR for different dump, for example SSH_CORE_COLLECTOR for ssh dump, and document the requirements.
Comment 6 Sarina Canelake 2010-07-16 06:36:34 UTC 
(In reply to comment #5)

> This is reasonable, but I am not sure. The interface of CORE_COLLECTOR is
> pretty limited, it requires sometimes to copy to stdout (then it only accepts
> one argument), sometimes to copy to another core file (then it accepts two
> arguments).
> 
> The best solution I can think of is to invent different CORE_COLLECTOR for
> different dump, for example SSH_CORE_COLLECTOR for ssh dump, and document the
> requirements.    

I think that is a good idea. It would certainly clear up a lot of usage issues to have more specific options rather than one catchall option with a bunch of different ways of using it. Document is also nice. I have trouble using kdump and crash sometimes because features are added without being documented. grr :)
Comment 8 Chao Ye 2010-08-03 08:42:40 UTC 
kdump.conf:
net root.65.161
core_collector cp
default shell

Verified with -116.el6:
============================================================
......
Saving to remote location root.65.161
1+0 records in
1+0 records out
Free memory/Total memory (free %): 215904 / 249524 ( 86.5263 )
BusyBox v1.15.1 (2010-06-01 08:04:20 EDT) multi-call binary

Usage: cp [OPTIONS] SOURCE DEST
......

Verified with -132.el6:
============================================================
......
Saving to remote location root.65.161
1+0 records in
1+0 records out
Free memory/Total memory (free %): 215972 / 249524 ( 86.5536 )
Copied 0.515625 MB / 1791.38 MB
......

Change status to VERIFIED.
Comment 9 releng-rhel@redhat.com 2010-11-11 14:45:16 UTC 
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.
Note You need to log in before you can comment on or make changes to this bug.