Bug 495049 - cpuspeed initscript yields some incorrect return values
Summary: cpuspeed initscript yields some incorrect return values
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: cpuspeed
Version: 5.3
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Jarod Wilson
QA Contact: BaseOS QE
URL:
Whiteboard:
Depends On:
Blocks: 237789
TreeView+ depends on / blocked
 
Reported: 2009-04-09 12:44 UTC by Karel Volný
Modified: 2013-04-12 20:11 UTC (History)
6 users (show)

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)
Clone Of:
Environment:
Last Closed: 2010-01-13 12:26:19 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2010:0035 0 normal SHIPPED_LIVE cpuspeed bug fix update 2010-01-13 12:25:53 UTC

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


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