Changset 22806:eefb8e971be5 broke 'xl'.
After starting the xenstored, xenconsoled, xenbackendd and running xl
create I get this:
libxl: error: libxl.c:53:libxl_ctx_init Is xenstore daemon running?
failed to stat /var/run/xenstore.pid: No such file or directory
cannot init xl context
The reason for the failure is that the NetBSD startup script
creates the file
/var/run/xenstored.pid
but libxl checks for
/var/run/xenstore.pid
Attached patch makes this consistent across Linux and NetBSD by
changing the Linux name (to the more-conventional food.pid form).
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
This is the default runlevel on a Debian system.
In addition update-rc.d complains:
update-rc.d: warning: xencommons stop runlevel arguments (0 1 6) do not match LSB Default-Stop values (1)
and it seems reasonable to stop the daemons during shutdown or reboot
so make that change as well.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Since 22187:c41252a55a0a we have been installing our example
xencommons settings file in either /etc/sysconfig or /etc/default,
depending on whether /etc/sysconfig exists.
However I omitted to add the code to /etc/init.d/xencommons to
actually read either version of the file, although every other init
script seems to have it.
An effect of this misplaced/unread file is that the automatic tests
don't cause xenconsoled to collect serial logs, because the tester
edits whichever file actually exists.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
# User Olaf Hering <olaf@aepfle.de>
# Date 1280140115 -3600
# Node ID 8c3e1e8ddd599371d882b17996be88b545119ccb
# Parent 2092c06f9467747da608c448ddd01e2f1f82290a
tools/hotplug: init.d should test for /proc/xen/capabilities being a file
Correct test for /proc/xen/capabilities
It is a file, not a directory.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
"Default-Enabled:" is not a LSB keyword.
Remove it from the LSB section.
This avoids an openSuSE buildcheck warning and we are not aware of any
reason why it should be kept.
From: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Modified-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
On one of my boxes, the xenstore-write setting dom0's name starts
before xenstored is actually ready to handle the connection properly,
resulting in the name set failing. Wait for xenstored to be up and
responding to reads before continuing, timing out after 30 seconds.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Fix the xencommons init script chkconfig configuration since the
priority was missing here and chkconfig was complaining about invalid
chkconfig script so I added both start and stop priorities to the
chkconfig line and it was working fine, the script was successfully
added to chkconfig when using `chkconfig --add xencommons` and
management using the chkconfig utility was now possible.
Tested on RHEL-5 Server with Xen-4.1-unstable installed, running on
PVops kernel 2.6.32.15 and it was working fine.
Signed-off-by: Michal Novotny <minovotn@redhat.com>
If xenfs is compiled as a module, now cannot complete
'service xencommons start', modprobe xenfs can fix it.
Signed-off-by: Yu Zhiguo <yuzg@cn.fujitsu.com>