Bug 495049

Summary: cpuspeed initscript yields some incorrect return values
Product: Red Hat Enterprise Linux 5 Reporter: Karel Volný <kvolny>
Component: cpuspeedAssignee: Jarod Wilson <jarod>
Status: CLOSED ERRATA QA Contact: BaseOS QE <qe-baseos-auto>
Severity: low Docs Contact:
Priority: low    
Version: 5.3CC: anton, dkovalsk, eguan, emcnabb, lbrindle, rlerch
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
some exit status codes from the initscript were not in line with LSB standards. The codes were updated, and are now compliant. (BZ#495049)
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-01-13 12:26:19 UTC Type: ---
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: 237789    

Comment 7 Jarod Wilson 2009-06-10 21:06:06 UTC
I believe I've got both 1 & 2 taken care of in a local build that I'm about to push into rawhide:

$ service cpuspeed blowup
Usage: /etc/init.d/cpuspeed {start|stop|restart|condrestart|status}
$ echo $?
2

$ service cpuspeed start
Insufficient privileges to start cpuspeed service:         [FAILED]
$ echo $?
4

Also adding misc other lsb compliance bits, per bug 246895.

Comment 9 RHEL Program Management 2009-11-06 19:05:34 UTC
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".

Comment 12 Eryu Guan 2009-12-11 04:36:20 UTC
cpuspeed-1.2.1-9.el5

Not sure:
* Return codes of the script:
  1 generic or unspecified error
  3 unimplemented feature

because test /CoreOS/cpuspeed/Regression/initscript failed on
these two cases. 
 - service cpuspeed start got return value 0 when 
   removing cpufrep kernel module and 1 is expected
 - test takes 'reload' as an unimplemented feature, 
   but service cpuspeed reload works just as restart

Verified:
* Return codes of the status command:
  0 program is running or service is OK
  1 program is dead and /var/run pid file exists
  2 program is dead and /var/lock lock file exists
  3 program is stopped

* Return codes of the script:
  2 invalid or excess argument(s)
  4 user had insufficient privilege
  5 program is not installed

Comment 13 Jarod Wilson 2009-12-15 23:11:49 UTC
We intentionally don't raise an alarm if cpuspeed doesn't start, because there's a lot of hardware that simply doesn't support it, and we enable the service by default. Raising an alarm on every system where cpuspeed couldn't start would add support call burden, and there's nothing we can do to fix (most) systems that don't support cpu frequency scaling.

Not sure what the complaint about reload is. There's nothing to reload in most cases, because its not a daemon, its in-kernel freq scaling, so we just do the same thing as a restart.

IMO, both of those can be ignored, things are operating as expected here.

Comment 15 Lana Brindley 2009-12-29 20:36:04 UTC
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.

New Contents:
some exit status codes from the initscript were not in line with LSB standards. The codes were updated, and are now compliant. (BZ#495049)

Comment 17 errata-xmlrpc 2010-01-13 12:26:19 UTC
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/RHBA-2010-0035.html