Bug 105677 - /etc/init.d/xend status
Summary: /etc/init.d/xend status
Status: RESOLVED FIXED
Alias: None
Product: SUSE LINUX 10.0
Classification: openSUSE
Component: Other (show other bugs)
Version: Beta 2
Hardware: Other All
: P5 - None : Normal
Target Milestone: ---
Assignee: Charles Coffing
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-08-18 20:42 UTC by Andreas Klein
Modified: 2006-01-25 22:52 UTC (History)
4 users (show)

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Klein 2005-08-18 20:42:18 UTC
/etc/init.d/xend returns no status
wpyc022:~ # /etc/init.d/xend status

wpyc022:~ # 

xend status is shown in yast2-> runlevel-editor as started. If you press the
stop button, you will see an error message, that the package is not installed.
But if it is not installed, how can the service be running?
Comment 1 Kurt Garloff 2005-08-19 18:15:29 UTC
Andreas, you confuse me: 
If the package is not installed /etc/init.d/xend is not there. 
Comment 2 Andreas Klein 2005-08-19 18:18:44 UTC
The package is installed. Yast says it is not installed, if you try to stop the
service :-) 
Comment 3 Kurt Garloff 2005-08-22 15:20:57 UTC
Hmm, is this a YaST bug then? 
Comment 4 Arvin Schnell 2005-08-23 08:26:08 UTC
Lukas?
Comment 5 Lukas Ocilka 2005-08-29 07:01:52 UTC
It seems that the package "xen" needs to be installed to appear in the
runlevel-editor (tested).

The second thing is, that the XEN still doesn't work in Beta2 (lslezak?).
See: /etc/init.d/xend line 27: xend status

`which xend`
`/usr/sbin/xend status` -->

--- cut ---
ERROR: Could not obtain handle on privileged command interface (2 = No such file
or directory)
Traceback (most recent call last):
  File "/usr/sbin/xend", line 36, in ?
    from xen.xend.server import SrvDaemon
  File "/usr/lib/python2.4/site-packages/xen/xend/server/SrvDaemon.py", line 29,
in ?
    import channel
  File "/usr/lib/python2.4/site-packages/xen/xend/server/channel.py", line 6, in ?
    import xen.lowlevel.xc; xc = xen.lowlevel.xc.new()
xen.lowlevel.xc.error: (2, 'No such file or directory')
--- cut ---

seems to be a problem in '/usr/sbin/xend' script
Comment 6 Kurt Garloff 2005-08-29 14:07:12 UTC
OK, I'll have a look. 
Comment 7 Kurt Garloff 2005-08-29 17:52:16 UTC
Hmm, this should be fixed in 
http://www.suse.de/~garloff/linux/xen/RPMs-100/6458/ 
Can you check, please? 
Comment 8 Andreas Klein 2005-08-31 13:22:06 UTC
No, doesn't help.
Comment 9 Kurt Garloff 2005-08-31 23:42:07 UTC
What am I doing wrong so I can't reproduce this? 
root@tpkurt:~ [0]# /etc/init.d/xend status 
Checking status of xend (pid 6756 6762 6763 6764 6765 6766 6901)                 
running 
root@tpkurt:~ [0]# rcxend stop 
Stopping xend (pid 6756 6762 6763 6764 6765 6766 6901)                           
done 
root@tpkurt:~ [0]# /etc/init.d/xend status 
Checking status of xend                                                          
unused 
root@tpkurt:~ [3]# 
 
And on a machine that is not running a xen kernel: 
root@prescott:~ [0]# /etc/init.d/xend status 
xend  
root@prescott:~ [5]#  
 
The return code should 3 instead of 5 I guess anbd the mesage could be 
improved, but that does not explain what you are seeing, does it? 
Comment 10 Kurt Garloff 2005-12-20 20:49:10 UTC
This should be fixed in the update packages. Can you confirm?
Comment 11 Andreas Klein 2005-12-20 21:02:51 UTC
A little bit.
The xend service is not shown as running. That's correct now.
When trying to stop the not running service still shows the same error-message.
I thing this is not lsb-compliant? Stopping a not running service must be successfull, or am I wrong?
Comment 12 Ladislav Slezák 2006-01-02 12:01:34 UTC
Yes, it must be successful (see /etc/init.d/skeleton file, there are usefull comments).
Comment 13 Lynn Bendixsen 2006-01-23 17:47:49 UTC
Charles Coffing has been doing some /etc/init.d/xend work and asked me to assign this to him to see if it is already fixed with his latest work.
Comment 14 Charles Coffing 2006-01-25 21:57:47 UTC
Fixed in 3.0_8659.  Retest in beta 3.
Comment 15 Charles Coffing 2006-01-25 22:52:38 UTC
changing to FIXED