Hide Forgot
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
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
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
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/