Bug 477023 - multipath always exits with EXIT_FAIL with -f/-F commands
multipath always exits with EXIT_FAIL with -f/-F commands
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: device-mapper-multipath (Show other bugs)
5.2
All Linux
medium Severity medium
: rc
: ---
Assigned To: Ben Marzinski
Cluster QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-18 13:07 EST by Bryn M. Reeves
Modified: 2010-10-23 02:39 EDT (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-02 07:47:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bryn M. Reeves 2008-12-18 13:07:05 EST
Description of problem:
Older versions of multipath-tools would always exit with status 0
(success) when flushing multipath device maps (-f/-F). This was never
guaranteed but happened because the "r" local in multipath/main.c was
used uninitialised in these code paths (by chance, it always lands on a
freshly zeroed stack page, so although undefined the behaviour was
pretty reliable).

This was changed by commit 8497928514aa3df6d46f24d8d9b70b086e9fcfbd:

commit 8497928514aa3df6d46f24d8d9b70b086e9fcfbd
Author: Christophe Varoqui <root xa-s05 (none)>
Date:   Mon Mar 13 14:55:16 2006 +0100

   [build] minor compilation issues

   SuSE checker found some minor issues:

   - refwwid in libmultipath/configure.c:get_refwwid() might be used
   uninitialized. As dev_type is a simple 'int' there is nothing which
   prevents the unsuspecting user to call it with an unhandled value.
   We shoud rather use an enum and set refwwid to NULL to be on the
   safe side.

   - attr in libmultipath/discovery.c:devt2devname() might be used
   uninitialized. Quite unlikely, but might happen in principle.
   So better have it initialized.

   - r in multipath/main.c:main() might be used uninitialized.
   True. So have it initialized.

This causes -f/-F in more recent versions of the tools to always exit
with status 1 (failure) which does not seem correct.

This was discussed on dm-devel and a patch is now in upstream that corrects this behaviour:

https://www.redhat.com/archives/dm-devel/2008-December/msg00046.html
https://www.redhat.com/archives/dm-devel/2008-December/msg00068.html

Version-Release number of selected component (if applicable):
device-mapper-multipath-0.4.7-17

How reproducible:
100%

Steps to Reproduce:
1. run "multipath -f" with some flushable maps present
2. echo $?
3.
  
Actual results:
Always exits with status 1

Expected results:
    multipath -f <map>
    ------------------
    
    -f     flush a multipath device map specified as parameter, if unused
    
    Exit Status
          0 The map existed and was successfully flushed
          1 The map did not exist or could not be flushed
    
    multipath -F
    ------------
    
    -F     flush all unused multipath device maps
    
    Exit status
          0 At least one unused multipath device map was flushed
          1 No unused maps were found or no maps could be flushed
    
Additional info:
Two commits needed for this, one to not treat attempts to flush non-mpath maps as an error and the second to or rather than sum the return of dm_flush_map():

    commit 80cac070fd5389a17ef82deb66f7c56c8c0b21af
    Author: Christophe Varoqui <christophe.varoqui@free.fr>
    Date:   Thu Dec 18 00:13:30 2008 +0100
    
        [lib] dm_flush_map on a non-multipath devmap do nothing and returns 0
        
        So that "multipath -F" can succeed when non-multipath maps are active
        on the system.
    
    commit 3237295a077327188c65456de180ec3027a8f783
    Author: Christophe Varoqui <christophe.varoqui@free.fr>
    Date:   Thu Dec 18 00:01:37 2008 +0100
    
        [lib] don't add up errors in dm_flush_maps()
        
        to avoid return code overflow, as pointed by "Bryn M. Reeves",
        Redhat.
Comment 1 Ben Marzinski 2009-05-04 14:17:22 EDT
Fix ported from upstream.
Comment 3 Chris Ward 2009-07-03 14:18:20 EDT
~~ Attention - RHEL 5.4 Beta Released! ~~

RHEL 5.4 Beta has been released! There should be a fix present in the Beta release that addresses this particular request. Please test and report back results here, at your earliest convenience. RHEL 5.4 General Availability release is just around the corner!

If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity.

Please do not flip the bug status to VERIFIED. Only post your verification results, and if available, update Verified field with the appropriate value.

Questions can be posted to this bug or your customer or partner representative.
Comment 5 errata-xmlrpc 2009-09-02 07:47:51 EDT
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/RHEA-2009-1377.html

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