similar to: Bug#628912: xenconsoled and xenstored stopping unhandled by init script

Package: xen-utils-common Version: 3.0.3-0-2 Severity: normal There should be a clean and clearly defined way to restart all the Xen daemons in the case of error. If the file /var/lib/xenstored/tdb is corrupt then you must stop xenstored, rm the file, and then restart it. Currently there is no defined way of doing this so the solution is to kill -9 the process, rm the file, and then reboot. --

Package: xen-utils-3.2-1 Version: 3.2.1-2 Severity: wishlist Hi, this morning I spend some time to find out how to log console output of Xen guest domains into a file in dom0. I ended up using a quick 'n dirty solution: mario:/usr/lib/xen-3.2-1/bin 0-# diff -u xend.orig xend --- xend.orig 2009-03-02 16:49:49.000000000 +0100 +++ xend 2009-03-02 16:16:03.000000000 +0100 @@ -100,7 +100,8 @@

Package: xen-utils-common Version: 3.4.2-3 Severity: normal If one daemon is running but the others are not then the stop script will fail. It should use the pid file for each daemon and try to stop them independently. Note that the fact that Xen shouldn't get into this state is not relevant, daemons do periodically fail, relevant system control scripts should be able to stop them even

Hi, I see a round of bug fixes and well as xenbus were pulled upstream. Is anything else going into .38? -- 2. That which causes joy or happiness. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Package: xen-hypervisor-4.1-amd64 Version: 4.1.4-3+deb7u4 Severity: critical Hi, Not sure how come I'm the first one to file this kind of a bug report :) but here goes JFTR... http://xenbits.xen.org/xsa/advisory-123.html was embargoed, but advance warning was given to several big Xen VM farms, which led to e.g. https://aws.amazon.com/premiumsupport/maintenance-2015-03/

Hi, Sometimes, seemingly randomly, long-running Xen domains, using clocksource xen, have their clock shift by ~3000 or ~36000 seconds, often with the dom0 complaining about clocksource tsc. The number changes if the hypervisor is explicitly told to use clocksource=pit, but it still happens. It doesn''t seem to be particularly hardware-specific. See also http://bugs.debian.org/599161 I

Grant references for the xenstore and xenconsole shared pages exist, but currently only xenstore uses these references. Change the xenconsole daemon to prefer using the grant reference over map_foreign_range when mapping the shared console ring. This allows xenconsoled to be run in a domain other than dom0 if set up correctly - for libxl, the xenstore path /tool/xenconsoled/domid specifies the

https://bugzilla.mindrot.org/show_bug.cgi?id=2110 Bug ID: 2110 Summary: ssh-copy-id fails on nonexisting private key Product: Portable OpenSSH Version: 6.2p1 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P5 Component: Miscellaneous Assignee: unassigned-bugs

Hello, Is there any documention on "xenconsoled" ? (I have installed xen from source) /usr/sbin/xenconsoled --help Usage: /usr/sbin/xenconsoled [-h] [-V] [-v] [-i] What do the different options mean? Should xenconsoled always be running, even when no "xm console" commands are active? I killed it in error, but now need to know how to start it with it''s default

Package: xen-utils-4.4 Severity: normal Dear Maintainer, the xen-utils-4.4 and xen-utils-4.1 prerm maintainer scripts contain the following code snippet: remove|upgrade) update-alternatives --remove xen-default /usr/lib/xen-4.4 if [ -x "/etc/init.d/xen" ]; then invoke-rc.d xen stop || exit $? fi ;; which, in conjunction with the postinst

One of our machines are being bitten by that bug, once every 2-4 weeks or so xenconsoled dies and all the VMs stop responding intil xenconsoled is restarted. I googled for it and I saw many people reporting it but no solution for it. Does anyone know if it is solved in 5.5? I can't upgrade the box (it's a production box) unless I can prove the problem will go away. thanks in advance

xenconsoled: do not write the pty under serial in xenstore if xenconsoled is handling a consolepath. The idea is that pv consoles use the "console" prefix in xenstore and emulated serials use the "serial" prefix in xenstore. There is no need to write the pty for a pv console under "serial", considering that xenconsoled is already writing the pty under

Hi Ian, On Tue, Jan 17, 2017 at 10:58 +0000, Ian Jackson wrote: > Wolodja Wentland writes ("Bug#851654: Prerm maintainer script unconditionally > stops xend/xenconsoled"): > We triggered a xen stop by removing obsolete > xen-utils-4.1 packages while already using xen-utils-4.4. > I think a xenconsoled restart should be harmless, so I think it is > probably right that

Hello list! I''ve noticed this problem a couple of times now.. so I''m wondering if it''s a known bug? Symptoms: After "long" dom0 uptime (174 days when it happened now, was something similar on previous times too) cannot start new pv domUs anymore.. pygrub runs and boots the kernel, but kernel newer gets to actually running initrd and the console output

retitle 571634 xen-utils-common vif-common.sh still using --physdev-out, --state found 571634 4.0.0-1 thanks Hi, That link to upstream patch in the last message is apparently broken, a working one is: http://xenbits.xen.org/hg/xen-unstable.hg/rev/b0fe8260cefa but also more importantly for the current stable package: http://xenbits.xen.org/hg/xen-4.0-testing.hg/rev/af7110f4f803 Because the

Grant references for the xenstore and xenconsole shared pages exist, but currently only xenstore uses these references. Change the xenconsole daemon to prefer using the grant reference over map_foreign_range when mapping the shared console ring. This allows xenconsoled to be run in a domain other than dom0 if set up correctly - for libxl, the xenstore path /tool/xenconsoled/domid specifies the

Under the right circumstances, xenconsoled will corrupt its internal list of domains causing a SEGV. This is usually characterized by a rapid number of creations/destructions. The attached patch fixes this. Regards, Anthony Liguori _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

As any other daemon, I''d assume it should be possible to restart xenstored (i.e. if it crashed or if, during development, a fix was made to it that needs to be tested). However, as I learned after over a day of digging, things don''t work anymore after doing so: Since the watches are transient, they''re lost with the daemon going away. Right now I specifically need this in

Processing commands for control at bugs.debian.org: > reassign 628912 xen-utils-common 4.0.1-2 Bug #628912 [xen-utils-4.0] xenconsoled and xenstored stopping unhandled by init script Bug reassigned from package 'xen-utils-4.0' to 'xen-utils-common'. No longer marked as found in versions xen/4.0.1-2. Ignoring request to alter fixed versions of bug #628912 to the same values

Package: xen-utils-common Version: 4.0.0-1 Severity: important After running modules_setup you need to have the following line: [ -x /sbin/restorecon ] && /sbin/restorecon -R /dev/xen The reason is that the module load causes the kernel to create device nodes in the devtmpfs. This bypasses the udev code for labelling the device node and results in xenstored being unable to access