Red Hat Bugzilla – Bug 268741
mkdumprd incorrectly reports remote filesystem space
Last modified: 2013-09-29 22:08:10 EDT
Description of problem:
When I rebuild my kdump image after updating kdump.conf, I am told that there
isn't space enough for the vmcore file on my remote server (for scp).
Warning: There is not space enough to save a vmcore.
The size of email@example.com:/var/crash/tmp.DOWHY25340 should be
much greater than 16502136 bytes.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Configure kdump to scp to a remote server
2. Make sure the remote server has less than your server's memory of USED
space on the appropriate filesystem
3. Restart kdump.
warning about less than 16G of space available
No warning when less than 16G of space used.
The remote_df check in mkdumprd is referencing field 10 of the output. This
field is the _used_ filesystem space. The _available_ filesystem space is
field 11. As long as there is sufficient _available_ space, we shouldn't get
Also, the message states that I should have at least that many _bytes_ of free
space. In actuality, it should be kilobytes.
Created attachment 181721 [details]
Created attachment 181761 [details]
patch to make df output posix compliant in ssh case
I think this is what you need. Please use it to patch mkdumprd and let me know
if it fixes your problem. Thanks
Created attachment 181921 [details]
Patch (method 1)
The simplest patch is a 1 character change from -f10 to -f11.
Created attachment 181941 [details]
Patch (method 2)
This is a patch that is based off Neil's patch...it tails the df output before
returning it to mkdumprd (to remove the column headers).
in response to comment 3: Thats also the wrong patch. The column number you cut
at will change based on the size of the mounted fs path, since w/o the -P option
on df it will insert newlines for readability.
in response to comment #4: Why are you tailing this twice?
Please just confirm the patch as I provided it to you. Thank you
The patch you provided eliminated the warning but did not do the proper
comparison. The result of your patch was (running with bash -x):
++ ssh -q -o BatchMode=yes -o StrictHostKeyChecking=no firstname.lastname@example.org
df -P /var/crash/tmp.QVTtV28107
+ remote_df='Filesystem 1024-blocks Used Available Capacity
/dev/cciss/c0d1p1 70005824 152748 69141852 1% /var/crash'
++ echo Filesystem 1024-blocks Used Available Capacity Mounted
on /dev/cciss/c0d1p1 70005824 152748 69141852 1% /var/crash
++ tail -1
++ tr -s ' ' '|'
++ cut '-d|' -f4
+ '[' Available -lt 16502136 ']'
/sbin/mkdumprd: line 1647: [: Available: integer expression expected
The second 'tail' is unneeded.
The field that is needed is number 11. This is regardless of the newlines
because of the way the output is returned and then echo'd.
remote_df may have newlines embedded, but when it is echo'd back for the
purporses of tailling, translating, and cutting, the newlines seem to be
ignored. (see above output).
Several ways around this are to use field 11 (since the newlines don't get
echo'd into the pipelined commands in the current incarnation of the code)
(aka patch in comment #3)...or to move the tail from the echo $remote_df line
to the ssh command (patch in comment #4 minus the second tail)...or to combine
the two and do all your pipelining within the ssh command so that the
available space is returned from that rather than the whole df output.
Created attachment 183161 [details]
corrected patch (method 2)
Created attachment 183181 [details]
this performs all the parsing of df within the ssh command and returns the
oops, your right, the tail does need to be on the remote side. I'll add the
patch from comment 7 to minimize remote side processing. Thanks. This will be
available in RHEL5.2
This has been fixed for quite a while. This should be able to be closed now.