Bug 1543954

Summary: RFE: Give retcode based on error
Product: Red Hat Enterprise Linux 7 Reporter: Jakub Krysl <jkrysl>
Component: vdoAssignee: Joe Shimkus <jshimkus>
Status: CLOSED ERRATA QA Contact: Jakub Krysl <jkrysl>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.5CC: awalsh, bgurney, jkrysl, jshimkus, limershe
Target Milestone: rcKeywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 6.1.1.28 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1603478 1603485 (view as bug list) Environment:
Last Closed: 2018-10-30 09:39:22 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1603478, 1603485    

Description Jakub Krysl 2018-02-09 16:16:03 UTC
Description of problem:
When vdo fails for some reason, it always returns retcode 2 no matter the error. There is some benefit in changing this behaviour to return retcode based on the error itself.

Version-Release number of selected component (if applicable):
6.1.0.146-16

How reproducible:
100%

Steps to Reproduce:
1. get vdo command to return error
2. check retcode
# echo $?

Actual results:
2

Expected results:
retcode based on error given by vdo CLI

Additional info:

Comment 3 Joe Shimkus 2018-03-14 12:51:40 UTC
The exit statuses have been modified as follows:

 1 - overall generic failure; this is what used to be 2
 2 - argument parsing failure; generated by pre-processing argument parsing
 3 - generic processing failure
 5 - state failure; some entity in incorrect state for requested action
 6 - system failure; a requested operation from the system failed
 7 - user failure

Examples:
 exit status 5: attempting to perform growPhysical on a stopped vdo
 exit status 6: failed file read
 exit status 7: parameter incongruities which are checked at runtime,
                user running with insufficient permission

Exit status 4 should never be seen; it's used in defensive programming against developer oversight. As an example, consider...

  switch (someValue) {
    case 0:
      // do something
      break;
    case 1:
      / do something else
      break;
    default:
      exit(4);
  }

If the range of someValue is extended without a corresponding change to the switch an exit status of 4 will result.

If a test gets an exit status of 4 it has definitely encountered a bug.

Comment 5 Joe Shimkus 2018-07-19 15:56:27 UTC
*** Bug 1603478 has been marked as a duplicate of this bug. ***

Comment 6 Joe Shimkus 2018-07-23 18:26:47 UTC
Added EXIT STATUS section to man page describing the various exit status values.  That is available in build  6.1.1.115.

Comment 7 Jakub Krysl 2018-09-14 14:38:19 UTC
man page:
EXIT STATUS
       The following are exit statuses that may be encountered during normal operation.  Any other exit status is an abnormal occurrence.

       0      Success.

       1      Non-specific failure.

       2      Pre-processing argument parsing failure.

       3      Non-specific processing failure.

       5      Incorrect state for requested action; e.g., attempting to perform a growPhysical on a stopped vdo.

       6      A requested operation from the system failed; e.g., error from dmsetup(8).

       7      User error; e.g., attempting to create a vdo with the same name as one already existing.


I am getting the different retcodes without any issues.

Comment 9 errata-xmlrpc 2018-10-30 09:39:22 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:3094