Description of problem: If a script specifies #!/bin/sh it fails silently. Version-Release number of selected component (if applicable): kexec-tools-1.102pre-21.el5_2.2 How reproducible: Steps to Reproduce: 1. Create a kdump_pre or kdump_post - specifying #!/bin/msh for the interpreter - containing echo commands. 2. restart kdump 3. echo "c" > /proc/sysrq-trigger 4. Observe console trace 5. Change the scripts interpreter to #!/bin/sh 6. restart kdump 7. echo "c" > /proc/sysrq-trigger 8. Observe console trace. Actual results: First console trace shows: - output from the pre/post scripts - successful execution of pre/post scripts Second console trace show: - no output from the pre/post scripts - successful execution of pre/post scripts Expected results: Second console trace should show either: - output from pre/post scripts - OR failure of pre/post script - OR refusal to execute pre/post script - e.g unrecognized interpreter Additional info:
can you provide the kdump.conf, kdump_pre and kdump_post scripts you used in this test. I'd like to reproduce this in the same way you did please.
Created attachment 314871 [details] trace of 3 kdump-post scripts and associated console output Attached is a trace illustrating behavior of three simplified kdump postscripts: Each case - cats the script - attempts to execute the script from the current shell - excerpts the kdump trace kdump traces were captured using a serial console (see bug 459625) Case 1: /bin/msh - shell execution emits "bad interpeter" message - kdump-post script execution succeeds Case 2: /bin/sh - shell execution succeeds - kdump-post script not excuted - expected kdump behavior would be a "bad interpreter" message Case 3: no interpreter specified - shell execution succeeds - kdump-post script not executed - expected behavior would be attempted execution using either the current or some default interpreter -- in this case both are /bin/msh Patching mkdumprd to generate additional tracing reveals that the "0: not found" is generated by the attempt to execute the script. So it doesn't fail silently after all, but the message is too cryptic be readily grasped in a situation where it is soon removed from the screen. Two issues are revealed: - The failure message should be clearer - Case 3 should succeed.
Ahh, I see your issue. /bin/sh is not actually supported in kdump. The use of /bin/sh is really there to make some other scripts work properly. Its not meant for pre and post script usage. You need to use the /bin/msh interpreter here, which in your above examples works properly. If you look at teh implementation of /bin/sh in the initramfs you see it assumes that your are calling sh -c, and it just gets aliased to /bin/msh anyway. Since the /bin/msh shell syntax is not quite like that of /bin/sh, I would rather not fool people into thinking they can use /bin/sh here. I'll update the kdump.conf man page to properly reflect this. Thanks!
Created attachment 314929 [details] patch to update kdump.conf man page clarification for the man page
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-0105.html