similar to: Bug#680528: xen-utils-common: Please disable xendomains auto-start

Package: xcp-xapi Version: 1.3.2-8 Severity: important During startup /etc/init.d/xendomains script is called. That script is installed with xen-utils-common witch xcp-xapi is depends on. That script calls /usr/sbin/xen as xen list &> /dev/null This 'xen' seems to call xapi: xen list ^Z [1]+ Stopped xen list root at lab-xh3:~# ps f PID TTY STAT TIME

Processing commands for control at bugs.debian.org: > reassign #680528 xen-utils-common Bug #680528 [xcp-xapi] xcp-xapi: /etc/init.d/xendomains cause xapi to hand during boot Bug reassigned from package 'xcp-xapi' to 'xen-utils-common'. No longer marked as found in versions xen-api/1.3.2-8. Ignoring request to alter fixed versions of bug #680528 to the same values previously

Dear Michael, I was looking up the status of the cran2deb effort and notice that you now have a PPA where new packages are landing and being built for Ubuntu. It looks like this is still a work in progress, but is already a fantastic resource for me and I hope it is something that you can continue to operate. I'm now installing many of these packages but some things I need are missing.

----- Forwarded message from Don Armstrong <don@donarmstrong.com> ----- Date: Thu, 30 Sep 2004 16:19:41 -0700 From: Don Armstrong <don@donarmstrong.com> Resent-From: Don Armstrong <don@donarmstrong.com> To: submit@bugs.debian.org Subject: Bug#274301: libflac4 segfaults on corrupt flac files Severity: normal Package: libflac4 Version: 1.1.0-11 Running ogg123 on

Hi, While booting I am getting Failed to start Xendomains - start and stop guests on boot and shutdown. See ''systemctl status xendomains.service'' for details. When tried to start manually, its also fails service xendomains restart Redirecting to /bin/systemctl restart xendomains.service Job failed. See system journal and ''systemctl status'' for

Hi, I have cloned the official repository and made a branch to try to sort out the issues I have with stock xendomains. When I try to stage my changes, I get this error:- [me@xen3 init.d]# git add xendomains The following paths are ignored by one of your .gitignore files: tools/hotplug/Linux/init.d Use -f if you really want to add them. fatal: no files added I can''t find the rule

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This tripped me up recently too, but i found i needed a different patch: 0 aesop:~# diff -u /etc/init.d/xendomains{.orig,} - --- /etc/init.d/xendomains.orig 2007-04-18 12:04:04.000000000 -0400 +++ /etc/init.d/xendomains 2007-04-18 13:00:28.000000000 -0400 @@ -128,9 +128,9 @@ parseln() { - - name=`echo "$1" | cut -c0-17` +

Package: xen-utils-common Version: 3.0.3-0-2 Severity: normal xendomains saves the active domains when shutting down. it get the list of active domains from the following command[1]: xm list | grep -v '^Name' the output of "xm list" is like: lichen:~# xm list Name ID Mem(MiB) VCPUs State Time(s) Domain-0

Hi everyone! I''m using Xen 3.1.2 and Heartbeat on a two-node CentOS 5.2 cluster, and I''m having a little problem with the xendomains script.. I applied the patch at http://xenbits.xensource.com/xen-unstable.hg?rev/01c8ccb551b0 but it throws a syntax error when XENDOMAINS_AUTO points to an empty directory.. I think the patch should check if $NAMES (line 333) is empty before using

Package: xen-utils-common Version: 3.0.3-0-2 Severity: important patch I ran into this problem when using xen on Debian/Etch. I have several virtual xen instanses, and I name them using their fully qualified DNS domain name. These machines have failed to start automatically when I booted the host machine, and I just recently found out why. During shutdown, I was messages like this: Error:

Processing commands for control at bugs.debian.org: > reassign 298783 xen-utils-common Bug#298783: xend is stopped before xendomains in debs Bug reassigned from package `sysv-rc' to `xen-utils-common'. > tags 298783 - wontfix Bug#298783: xend is stopped before xendomains in debs Tags were: wontfix Tags removed: wontfix > thanks Stopping processing here. Please contact me if

Package: xen-utils-common Version: 4.1.3-4 Function check_running in /etc/init.d/xendomains incorrectly detects a not running domain as running. As a consequence thereof "/etc/init.d/xendomains stop" needs more than XENDOMAINS_STOP_MAXWAIT * "number of xen domains known to xend" seconds to run. Here is a pseudo call trace: do_stop_shutdown() { ... while read id name

xendomains init and default are fixed in debian/ and not updated for a long time. This is a commit based on new git when I did fast update and test: https://github.com/Fantu/pkg-xen/commit/4e975f306b8186bdcc02e0165516167d6fe8930b Thanks for any reply and sorry for my bad english. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type:

Source: xen Version: 4.4.0-4 Severity: normal Xendomains init and default files are taken from debian folder instead source and are not updated for some years. Please update them from upstream source. I did a fast update and test of them available here: https://github.com/Fantu/pkg-xen/commit/4d1914776256d209665d490182cf662f70cda619 -- System Information: Debian Release: jessie/sid APT prefers

There is some ugliness in the current version (4.4.1-2) although it doesn't seem to actually break anything in my case. From /var/log/boot: /etc/init.d/xendomains: line 128: domains: bad array subscript Starting Xen domain (from /etc/xen/auto/dnsmaster.cfg).../etc/init.d/xendomains: line 135: domains: bad array subscript

Source: xen Severity: wishlist Hi, xendomains init and default files in debian folder is not updated from upstream onesfor some years. Some parameters are missed. The more useful parameters when mainly windows domUs are used is XENDOMAINS_CREATE_USLEEP that I setted to 30 or 40 seconds on my systems to decrease the "overload" caused by windows startup (even if pv drivers are installed).

Control: tag -1 +moreinfo Hello, It seems this was incorrectly closed as xend only since this code can be used on upgrade (as part of rebooting from xend into a new system). I don't have any systems to test but I think the fix is trivially the following: @@ -51,7 +51,7 @@ class DataJSON(Data): class DataSXP(Data): def __init__(self, p): - s = SXPParser()(p) + s =

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Ian, you can use the patch I posted in the original report, there are two places that need to be fixed. I'm using it since November. Cheers, Volker -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlXXpS8ACgkQgKD4KXUzSriihQCgidnLz9Lx475uQ4dzWz4jDrzM nsUAn3Z/Sy3tA2yquXvyAXnY04pxgOop =GYjR -----END PGP SIGNATURE-----

On Sat, 2015-08-22 at 00:24 +0200, Volker Klasen wrote: > Hi Ian, > > you can use the patch I posted in the original report, Uh, how on earth did I miss it! > there are two > places that need to be fixed. I'm using it since November. Thanks. Since loads is a classmethod I think the right fix for that issue is to s/self/cls/ in the body rather than s/cls/self/ in the

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I've updated the feature/bug763102 with the following extra patch: With both your patches applied, xen-init-list works. Cheers, Volker -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlXZ2cgACgkQgKD4KXUzSrhELACg2CCtFNUPtHxNz7XgpQjaYH6b Gn4An26yNob9A7vhz1L8RTWTMCrfc6RY =M2dx -----END PGP SIGNATURE-----