Bug 459614 - kdump's dumprd not rebuilding when appropriate.
kdump's dumprd not rebuilding when appropriate.
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kexec-tools (Show other bugs)
5.2
All Linux
medium Severity medium
: rc
: ---
Assigned To: Neil Horman
:
: 471306 474365 (view as bug list)
Depends On:
Blocks: 468087 592312
  Show dependency treegraph
 
Reported: 2008-08-20 11:34 EDT by Rich Johnson
Modified: 2011-01-24 18:16 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 592312 (view as bug list)
Environment:
Last Closed: 2009-01-20 15:59:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to check stamps on other file (1.05 KB, patch)
2008-08-20 13:56 EDT, Neil Horman
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:0105 normal SHIPPED_LIVE kexec-tools bug fix and enhancement update 2009-01-20 11:04:36 EST

  None (edit)
Description Rich Johnson 2008-08-20 11:34:59 EDT
Description of problem:
kdump's initrd not rebuilt after updating:
  - kdump_pre script
  - any of the extra_modules
  - core_collector
  - etc.

Version-Release number of selected component (if applicable):
  kexec-tools-1.102pre-21.el5_2.2


How reproducible:


Steps to Reproduce:
for any of the required components listed in /etc/kdump.conf:
  - touch the component
  - restart kdump service
  - check whether the dumprd is rebuilt with the touched component. 1.

  
Actual results:
  dumprd rebuilt after touching kdump_post script
  dumprd not rebuilt after touching kdump_pre script
  dumprd rebuilt after touching kernel
  dumprd not rebuilt after touching a module  

Expected results:
  dumprd rebuilt in all cases.

Additional info:
Comment 1 Neil Horman 2008-08-20 13:56:38 EDT
Created attachment 314642 [details]
patch to check stamps on other file

This should suck in the extra files that need checking.  Please test and confirm.  the kernel image was already included in that list however.  CAn you tell me a bit more about what file you touched, how you verified the timestamp was modified and what you observed when the kdump service was restarted.

Thanks!
Comment 2 Rich Johnson 2008-08-22 16:50:18 EDT
testing was:
 - touch an input file
 - service kdump restart

Findings:
  - kdump_pre script is properly checked
  - kdump_post script is properly checked
  - extra_bins was not tested, but I see no reason to think the same change wouldn't work here
These changes are definitely worth taking.


  - extra_modules does not work as expected.  Listing any extra module causes a dumprd rebuild.

I think the problem is because the kernel modules are referenced by name and not by path.  There's also a subtlety here that modules.dep should be traversed to check dependencies.--otherwise updating the dependency will not trigger rebuilding the dumprd.
Comment 3 Neil Horman 2008-08-25 14:56:33 EDT
 - extra_modules does not work as expected.  Listing any extra module causes a
dumprd rebuild.


Not sure what you mean by that?  Did you mean to say that it does _not_ cause a rebuild?  Or does it cause a rebuild when it should not?
Comment 4 Rich Johnson 2008-08-25 16:16:38 EDT
What I meant was that date_check for the extra_modules needs to be more sophisticated.  

Modules are listed by module name, not file path--not the least because the path is dependent on the kernel version.  For example:

    extra_modules ipmi_msghandler 

references kernel module file:
  
   /lib/modules/2.6.18-92.1.10.el5/kernel/drivers/char/ipmi/ipmi_msghandler.ko

Treating the extra_modules as files as in:

+	CHECK_FILE=`grep ^extra_modules $KDUMP_CONFIG_FILE | cut -d\  -f2-`
+	EXTRA_FILES="$EXTRA_FILES $CHECK_FILE"

causes the dumprd to be rebuilt every time the kdump service is started because the file "ipmi_msghandler" does not exist.

The trace is:
   #> service kdump restart
   Stopping kdump:                                            [  OK  ]
   Detected change(s) the following file(s):
  
      ipmi_msghandler
   Rebuilding /boot/initrd-2.6.18-92.1.10.el5kdump.img
   Starting kdump:                                            [  OK  ]
Comment 5 Rich Johnson 2008-08-26 10:40:34 EDT
(In reply to comment #4)
> What I meant was that date_check for the extra_modules needs to be more
> sophisticated.  
> 
[...snip...]
IOW, /lib/modules/$(uname -r)/modules.dep is rquired to dereference module names and dependencies.

For exmample:

for mod in $extra_modules
do
    mod_ref=$(grep "/$mod.ko:" /lib/modules/$(uname -r)/modules.dep)
    mod_file=$(echo $(mod_ref) | cut -d':' -f1)
    #...check $mod_file
    mod_deps=$(echo $(mod_ref) | cut -d':' -f2)
    #...recursively check $mod_deps
done

Or if it's a safe assumption that modules.dep is updated everytime a module is changed, then the following might suffice at the expense of an occasion unnecessary rebuild.

if [ "$(grep '^extra_modules' KDUMP_CONFIG_FILE | cut -d\  -f2- ) -ne "" ]
then
    EXTRA_FILES="$EXTRA_FILES /lib/modules/$(uname -r)/modules.dep
fi
Comment 6 Neil Horman 2008-09-02 11:29:03 EDT
I think perhaps the safest thing to do is look to see if extra_modules is non-null and rebuild if it has anything listed.  Its overkill, but it saves us having to worry about wierd cases, like if someone has a 3rd parth module that doesn't update the dep tree or some such.

I've checked this and the extra_modules detection into -35.el5.
Comment 9 Neil Horman 2008-11-25 07:20:59 EST
yes, already reported, slated to be fixed in 5.4
Comment 13 Neil Horman 2008-12-03 10:44:46 EST
*** Bug 474365 has been marked as a duplicate of this bug. ***
Comment 14 Neil Horman 2008-12-03 14:08:52 EST
*** Bug 471306 has been marked as a duplicate of this bug. ***
Comment 17 errata-xmlrpc 2009-01-20 15:59:41 EST
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

Note You need to log in before you can comment on or make changes to this bug.