Bug 1696994

Summary:	Wrong exit code on init script failure
Product:	Red Hat Software Collections	Reporter:	Michal Schorm <mschorm>
Component:	mariadb	Assignee:	Michal Schorm <mschorm>
Status:	CLOSED WONTFIX	QA Contact:	Lukáš Zachar <lzachar>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	rh-mariadb102	CC:	databases-maint, mmuzila
Target Milestone:	---
Target Release:	3.4
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-04-27 10:50:59 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:	1828159, 1880319

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.