Bug 492139 - kernel-xen does not depend on xen
kernel-xen does not depend on xen
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: cpuspeed (Show other bugs)
5.3
All Linux
low Severity medium
: rc
: ---
Assigned To: Jarod Wilson
BaseOS QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-25 11:17 EDT by Karel Volný
Modified: 2013-04-12 16:09 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-15 06:05:29 EDT
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)
Description Karel Volný 2009-03-25 11:17:43 EDT
Description of problem:
While testing cpuspeed, I have found that if kernel-xen is booted, the (new) cpuspeed initscript tries to use the "xm" command to determine the number of pcpus/vcpus. But as xm is part of the xen package, it may happen that it is unavailable ...

Version-Release number of selected component (if applicable):
kernel-xen-2.6.18-128.el5
cpuspeed-1.2.1-6.el5

How reproducible:
always

Steps to Reproduce:
1. install and boot kernel-xen
2. service cpuspeed start
  
Actual results:
[root@dell-pe2850-04 ~]# service cpuspeed start
/etc/init.d/cpuspeed: line 120: xm: command not found
/etc/init.d/cpuspeed: line 121: xm: command not found
/etc/init.d/cpuspeed: line 122: [: : integer expression expected

Expected results:
(cpuspeed proceeds normally)

Additional info:
It would be logical for cpuspeed to depend on packages containing programs it uses. However, I do not see any point in depending on the whole xen dependency chain "just in case" the cpuspeed runs on xen-enabled system. On the other hand, booting kernel-xen and not running xend, although possible, does not make much sense, and so I think (*IMHO*) adding the dependency to kernel-xen would be viable. Therefore I file the bug against kernel-xen.
Comment 1 Daniel Berrange 2009-03-25 15:36:44 EDT
IMHO there is no need for any dependancy from kernel-xen -> xen RPMs to solve this. The cpuspeed initscript should simply test to see whether xm exists, eg

  test -x /usr/bin/xm

and not try running it if it doesn't exist.
Comment 2 Chris Lalancette 2009-03-27 10:53:43 EDT
Yeah, I have to say I agree with Dan about this one; it's a simple one-line change to cpuspeed, so I think we should do it that way, rather than changing the dependencies.  After all, technically, kernel-xen does not depend on xen; you can happily run the xen kernel without the tools (although it's kind of useless).

Chris Lalancette
Comment 4 Karel Volný 2009-03-27 16:06:44 EDT
(In reply to comment #1)
> The cpuspeed initscript should simply test to see whether xm exists, eg
> 
>   test -x /usr/bin/xm
> 
> and not try running it if it doesn't exist.  

the catch is that it uses xm to find pcpus and vcpus numbers, see bug #488924

I am not sure if this can be worked around ... adding a dependency seemed obvious to me, let's go ahead if there is a better way
Comment 5 Daniel Berrange 2009-03-27 16:16:50 EDT
IMHO this problem doesn't justify adding the dependancy. The usage in question:

    if [ -d "$xendir" ]; then
      vcpus=$(xm list Domain-0 | tail -n 1 | awk '{print $4}')
      pcpus=$(xm info | grep nr_cpus | awk '{print $3}')
      if [ "$vcpus" -ne "$pcpus" ]; then
        echo "CPU freq scaling under Xen when vcpus != pcpus is not supported"
        return 6
      fi
    fi


is merely adding a sanity check. 

It is easy enough to work deal with the lack of 'xm', by adding a further check just before this

  if [ -d "$xendir" && ! -x /usr/bin/xm ]; then
      echo  "Not running CPU freq scaling under Xen because xm is not installed"
      return r6
  fi
Comment 6 Karel Volný 2009-03-27 16:54:58 EDT
isn't there a way how to get the numbers without running the xen service and using xm? - to me it seems unfortunate to give up on cpufreq completely just because of this ... although it is not that important, as I see it only as a marginal case resulting from misconfiguration rather than desired system setup

let's see what Jarod thinks about it ...?
Comment 7 Jarod Wilson 2009-03-27 17:05:36 EDT
The use of xm was about all clalance and I could come up with when discussing the matter. The problem is that one of the two numbers comes from the hypervisor, and the only way I'm aware of to query into the hypervisor is via an xm call. Sure, we could grep /proc/cpuinfo on dom0 to get its vcpu count, but we're still stuck needing a way to get info out of the hypervisor. I think Dan's suggestion in comment #5 looks sane. This is just a corner-case sanity check, not something to get horribly worried about.
Comment 8 Jarod Wilson 2009-03-30 09:44:27 EDT
The only other thing we might want to add is a check to see that xm can actually connect to xend. I think this might actually cover that and the check to see that xm is present:

if [ -d "$xendir" ]; then
  foo=$(xm list 2>&1 > dev/null)
  if [ $? -ne 0 ]; then
    echo "No soup for you, unable to talk to xend."
    return 6
  fi
fi

If xm is missing $? should be 127. If is present but can't connect to xend, $? should be 1. If all is well, we get 0. Sound like a plan?
Comment 17 errata-xmlrpc 2009-04-15 06:05:29 EDT
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-2009-0424.html

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