Bug 495049 - cpuspeed initscript yields some incorrect return values
cpuspeed initscript yields some incorrect return values
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: cpuspeed (Show other bugs)
5.3
All Linux
low Severity low
: rc
: ---
Assigned To: Jarod Wilson
BaseOS QE
:
Depends On:
Blocks: 237789
  Show dependency treegraph
 
Reported: 2009-04-09 08:44 EDT by Karel Volný
Modified: 2013-04-12 16:11 EDT (History)
6 users (show)

See Also:
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 07:26:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Comment 7 Jarod Wilson 2009-06-10 17:06:06 EDT
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 Product and Program Management 2009-11-06 14:05:34 EST
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-10 23:36:20 EST
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 18:11:49 EST
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 15:36:04 EST
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 07:26:19 EST
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.