Description of problem: The LSB states that stop-after-stop should be considered successful. http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html [quote] For all other init-script actions, the init script shall return an exit status of zero if the action was successful. Otherwise, the exit status shall be non-zero, as defined below. In addition to straightforward success, the following situations are also to be considered successful: ... * running stop on a service already stopped or not running ... [/quote] Version-Release number of selected component (if applicable): squid-2.6.STABLE6-4.el5, squid-2.6.STABLE21-3.el5 How reproducible: 100% Steps to Reproduce: 1. service squid stop 2. service squid stop 3. echo $? Actual results: 1 Expected results: 0 Additional info: This effectively renders the 'squid' init script unsuitable for use in clustered environments, as we rely on the return codes being LSB compliant. Attached is a proposed patch; I do not know if it is sufficient or not.
Created attachment 360116 [details] Naive proposed fix
This is fixed and tested in Fedora checking for lock file. I propose back-porting. Jiri
Backporting from an existing, working solution is preferable.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2010-0221.html