Bug 184454 - xend initscript exit code is inconsistent
xend initscript exit code is inconsistent
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xen (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Veillard
:
Depends On:
Blocks: 179599
  Show dependency treegraph
 
Reported: 2006-03-08 17:06 EST by Brian Brock
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-13 16:43:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Brian Brock 2006-03-08 17:06:17 EST
Description of problem:


Version-Release number of selected component (if applicable):
xen-3.0.1-3

How reproducible:
varies with kernel flavor

under 2.6.15-1.2032_FC5xen0 the xend initscript gives the exit codes:
# service xend status
# echo $?
3
# service xend start
# echo $?
0
# service xend status
# echo $?
0

So, under -xen0, an exit code of 0 from `service xend` indicates that xend is
successfully running.

Under 2.6.15-1.2032_FC5smp:

# service xend status
# echo $?
0
# service xend start
# echo $?
0
# service xend status
# echo $?
0

Expected results:
Exit codes of commands should be consistent - 0 should not indicate success on
one kernel, and failure on another.  The exit codes aren't useful as they
currently exist.
Comment 1 Brian Stein 2006-10-26 16:25:47 EDT
Is this bug still valid?  If not, please close.
Comment 2 Brian Brock 2006-11-13 16:40:59 EST
kernel-2.6.18-1.2740.el5
xen-3.0.3-6.el5

Currently, xend appears to always return 0.

Checked permutations of start, stop, status with xend running.  Also checked
initscript commands under the non-xen kernel.

Initscript commands (e.g. `service xend start`) under the non-xen kernel fail
silently.
Comment 3 Brian Brock 2006-11-13 16:43:19 EST
above behavior actually looks like a different bug, I'll search and file another
that's more appropriate.

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