Bug 184454

Summary: xend initscript exit code is inconsistent
Product: [Fedora] Fedora Reporter: Brian Brock <bbrock>
Component: xenAssignee: Daniel Veillard <veillard>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 5CC: katzj, xen-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-11-13 21:43: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: 179599    

Description Brian Brock 2006-03-08 22:06:17 UTC 
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 20:25:47 UTC 
Is this bug still valid?  If not, please close.
Comment 2 Brian Brock 2006-11-13 21:40:59 UTC 
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 21:43:19 UTC 
above behavior actually looks like a different bug, I'll search and file another
that's more appropriate.