Bug 860780 - output from aeolus-restart-services is misleading, reports both success and failure
Summary: output from aeolus-restart-services is misleading, reports both success and f...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: CloudForms Cloud Engine
Classification: Retired
Component: aeolus-configure
Version: 1.1.0
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: beta3
Assignee: Steve Linabery
QA Contact: Rehana
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-09-26 17:04 UTC by Giulio Fidente
Modified: 2012-12-04 15:21 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-12-04 15:21:54 UTC
Embargoed:


Attachments (Terms of Use)
aeolus-restart-service output (8.25 KB, text/x-log)
2012-09-26 17:04 UTC, Giulio Fidente
no flags Details
log file (1.25 KB, application/octet-stream)
2012-10-02 23:53 UTC, Shveta
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2012:1516 0 normal SHIPPED_LIVE CloudForms Cloud Engine 1.1 update 2012-12-04 19:51:45 UTC

Description Giulio Fidente 2012-09-26 17:04:31 UTC
Created attachment 617669 [details]
aeolus-restart-service output

Description of problem:
The output from 'aeolus-restart-services' is misleading; reports both 'success' and 'failed' for the same action (eg. stopping a service already stopped). See log attached, in the start condition all services are stopped.

Version-Release number of selected component (if applicable):
aeolus-configure-2.8.7-1.el6cf

Steps to Reproduce:
1. install and configure the aeolus suite
2. stop some or all the services
3. launch 'aeolus-restart-services'
  
Actual results:
the output is misleading and also including a ruby stacktrace when unable to conntact postgresql

Expected results:
exit code from all services start/stop scripts should just produce an 'OK' or 'FAILED' state

NOTE:
as per LSB4.1, stopping an already stopped service should be considered a success:
http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html

the postgresql init script is the only one which seems to be compliant with that statement

Comment 3 Steve Linabery 2012-09-28 17:47:51 UTC
I'd just like to mention that all the scripts (with the possible exception of the deltacloud-core initscript, but that may be a bug) exit 0, but the output from `service foo stop` is often '[FAILED]' even if the exit is clean.

So my fix for this is to discard the STDOUT output from `service foo {action}` if the exit status from the system process is zero. We still output the STDOUT from `service` if it exits non-zero.

Comment 4 Mike Orazi 2012-10-01 13:56:10 UTC
Commit in master:  04228ee74886bc13dd29e9f00946e7983a5f0646
Commit in 1.1:  d391a97762e1dad656b443be8a2437436c58fa5a

Comment 6 Shveta 2012-10-02 23:53:13 UTC
Created attachment 620564 [details]
log file

Stopped some services and restarted aeolus-services.
As shown in the attached log file .. the O/p of "service foo stop" is not displayed and only sucess is displayed if the service is restarted sucessfully

 rpm -qa|grep aeolus
aeolus-conductor-doc-0.13.16-1.el6cf.noarch
aeolus-configure-2.8.8-1.el6cf.noarch
rubygem-aeolus-cli-0.7.3-1.el6cf.noarch
rubygem-aeolus-image-0.3.0-12.el6.noarch
aeolus-conductor-0.13.16-1.el6cf.noarch
aeolus-conductor-daemons-0.13.16-1.el6cf.noarch
aeolus-all-0.13.16-1.el6cf.noarch

Comment 7 Shveta 2012-10-02 23:58:08 UTC
However i think colon needs to be removed from Success 

[root@dell-pe1800-01 ~]# aeolus-check-services 

Checking mongod ...
 Success:

Checking iwhd ...
 Success:

Checking postgresql ...
 Success:

Checking httpd ...
 Success:

Checking deltacloud-core ...
 Success:

Checking libvirtd ...
 Success:

Checking aeolus-conductor ...
 Success:

Checking conductor-delayed_job ...
 Success:

Checking conductor-dbomatic ...
 Success:

Checking imagefactory ...
 Success:

Checking ntpd ...
 FAILURE: ntpd is stopped



Colon should be displayed only if there is a message like in case of Failure.

Comment 9 errata-xmlrpc 2012-12-04 15:21:54 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2012-1516.html


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