Bug 1696994 - Wrong exit code on init script failure
Summary: Wrong exit code on init script failure
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Software Collections
Classification: Red Hat
Component: mariadb
Version: rh-mariadb102
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
: 3.4
Assignee: Michal Schorm
QA Contact: Lukáš Zachar
URL:
Whiteboard:
Depends On:
Blocks: 1828159 1880319
TreeView+ depends on / blocked
 
Reported: 2019-04-06 23:47 UTC by Michal Schorm
Modified: 2020-09-18 09:50 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-27 10:50:59 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Michal Schorm 2019-04-06 23:47:22 UTC
Applicable only on RHEL6.

--

Service file:
  /etc/rc.d/init.d/rh-mariadb101-mariadb

Contains line:
  /opt/rh/rh-mariadb101/root/usr/libexec/mysql-prepare-db-dir $MYUSER $MYGROUP >/dev/null || return 4

--

However the exit code "4" is not correct as per:
  http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptact.html

The correct exit code on failure should be "1".

--

This behaviour also lead to Test case failure:
  /CoreOS/mariadb/Regression/bz1335849-MariaDB-removes-all-databases

--

Originally filed against 10.1 collection as #1558044

--

Not applicable on later (10.3+) MariaDB collections, as they are not released for RHEL6.

Comment 2 Michal Schorm 2019-04-06 23:58:24 UTC
Looks like this exit code was brought from Fedora when updating RHEL 5.5.40 SPECfile to 10.0.15

Comment 3 Michal Schorm 2019-04-08 14:40:26 UTC
DEV notes:
  * we won't fix it in the already released collection to prevent issues on the customer's side who might rely on the return code.
QA note:
  * the test should be enhanced to accept this error code as an expected behaviour for MariaDB collections.

Comment 5 Michal Schorm 2020-04-27 10:50:59 UTC
Closing as WON'T FIX with a justification as in comment 3.

Still setting BLOCKS to the tracker bug, as a reminder for QA that this issue exists.


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