Bug 1402322

Summary: initscript - wrong status code for dead service
Product: Red Hat Software Collections Reporter: Karel Volný <kvolny>
Component: mariadbAssignee: Michal Schorm <mschorm>
Status: CLOSED EOL QA Contact: qe-baseos-daemons
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rh-mariadb100CC: databases-maint, hhorak
Target Milestone: ---   
Target Release: 3.0   
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: 2018-05-03 08:47:01 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:
Bug Depends On:    
Bug Blocks: 1346768    

Description Karel Volný 2016-12-07 09:10:20 UTC
Description of problem:
When the daemon gets killed, service status does not return proper error code.

Version-Release number of selected component (if applicable):
rh-mariadb100-mariadb-server-10.0.28-5.el6.x86_64

How reproducible:
always

Steps to Reproduce:
1. run /CoreOS/mariadb/Regression/bz1037748-MySQL-server-does-not-restart-after-unclean-reboot

Actual results:
:: [  BEGIN   ] :: Killing mysql* :: actually running 'pkill -9 mysql\*'
:: [   PASS   ] :: Killing mysql* (Expected 0, got 0)
:: [  BEGIN   ] :: Service status should be 'dead but subsys locked' :: actually running 'service rh-mariadb100-mariadb status'
rh-mariadb100-mariadb dead but pid file exists
:: [   FAIL   ] :: Service status should be 'dead but subsys locked' (Expected 2,3, got 1)


Expected results:
:: [  BEGIN   ] :: Killing mysql* :: actually running 'pkill -9 mysql\*'
:: [   PASS   ] :: Killing mysql* (Expected 0, got 0)
:: [  BEGIN   ] :: Service status should be 'dead but subsys locked' :: actually running 'service rh-mariadb100-mariadb status'
rh-mariadb100-mariadb dead but pid file exists
:: [   PASS   ] :: Service status should be 'dead but subsys locked' (Expected 2,3, got 2)


Additional info:
see also bug 1194665

Comment 2 Honza Horak 2017-11-10 07:49:17 UTC
I don't see anything wrong what rh-mariadb100-mariadb init script does, and looking into /etc/rc.d/init.d/functions, "return 1" is what corresponds with this status. Whether it is correct according to the standard, I can't tell, but to be honest, is it worth exploring more? I doubt.

# grep -n -C 5 -e 'pid file exists' /etc/rc.d/init.d/functions
339-		done < "$pid_file"
340-
341-	        if [ -n "$pid" ]; then
342-	                return 0
343-	        fi
344:		return 1 # "Program is dead and /var/run pid file exists"
345-	fi
346-	return 3 # "Program is not running"
347-}
348-
349-# Output PIDs of matching processes, found using pidof
--
610-		0)
611-			echo $"${base} (pid $pid) is running..."
612-			return 0
613-			;;
614-		1)
615:	                echo $"${base} dead but pid file exists"
616-	                return 1
617-			;;
618-		4)
619-			echo $"${base} status unknown due to insufficient privileges."
620-			return 4

Comment 3 Karel Volný 2017-12-13 11:22:33 UTC
well, the thing is that lockfile check should take precedence (or at least that is how it was in the past, see the linked bug)

and since /var/lock/subsys/rh-mariadb100-mariadb exists, 2 should be returned, according to http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptact.html

if is it worth ... well, at least the scripts should behave consistently and return the same exit code under the same circumstances - if there had been reason to change the behaviour, then the reason probably had enough weight for this to be worth being resolved somehow

Comment 5 Honza Horak 2018-05-03 08:47:01 UTC
In accordance with the Red Hat Software Collections Product Life Cycle, the support period for this collection has ended.

New bug fix, enhancement, and security errata updates, as well as technical support services will no longer be made available for this collection.

Customers are encouraged to upgrade to a later release.

Please contact Red Hat Support if you have further questions, or refer to the support lifecycle page for more information. https://access.redhat.com/support/policy/updates/rhscl/