@paelzer,
glad to see you reproduce the problem successfully,
and simulate by creating nested KVM is better the my test, thanks
here I would like to add more history for this bug report,
* it is running under KVM with multiple instance
* it is ungracefully shut-down (could be simulated by virsh
forget to mention,
the RAID system I mentioned above, it is talking about software-raid system,
there's no raid card on server
hope these info would help :)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
@paelzer,
by the way, the final patch that merged into Yakkety is "sleep 0.5"
see "diff from 1.3.4-1ubuntu3 to 1.3.4-1ubuntu4 (1.6 KiB)"
- https://launchpad.net/ubuntu/+source/libvirt/1.3.4-1ubuntu4
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
@paelzer,
glad to see people start re-work on this issue, but it's been 16+ months
old,
I can only tell the scenario I remember,
I think it would not happened if it is already booted,
it is only happened *at boot time*, as I describe in originally message,
key points are,
* it is running with
** Changed in: corosync (Ubuntu)
Assignee: (unassigned) => guessi (guessi)
** Changed in: corosync (Ubuntu)
Status: New => In Progress
** Changed in: corosync (Ubuntu)
Status: In Progress => Fix Committed
--
You received this bug notification because you are
** Patch added: "wily.patch"
https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1586876/+attachment/4672672/+files/wily.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1586876
Title:
** Patch added: "yakkety.patch"
https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1586876/+attachment/4672674/+files/yakkety.patch
** Tags added: corosync
** Tags removed: corosync
** Tags added: precise
** Tags added: corosync trusty vivid wily xenial yakkety
--
You received this
** Patch added: "xenial.patch"
https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1586876/+attachment/4672673/+files/xenial.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1586876
Title:
** Patch added: "trusty.patch"
https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1586876/+attachment/4672670/+files/trusty.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1586876
Title:
** Patch added: "precise.patch"
https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1586876/+attachment/4672669/+files/precise.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1586876
Public bug reported:
Problem description:
currently, we have no service state check after start-stop-daemon in do_start(),
it might lead to an error if corosync report itself started too early,
pacemaker might think it is a 'heartbeat' backended, which is not we desired,
we should check if
** Patch added: "vivid.patch"
https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1586876/+attachment/4672671/+files/vivid.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1586876
Title:
@serge, great thanks! looking for LTS (trusty/xenial).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1571209
Title:
Sockfile check retries too short for a busy system boot
To manage notifications
@serge, is there any milestone to fix this rare case problem?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1571209
Title:
Sockfile check retries too short for a busy system boot
To manage
Public bug reported:
it's okay for booting ubuntu 16.04 (xenial),
but when I trying to add the line below, it just hang.
" d-i live-installer/net-image string http://10.10.1.1/ubuntu-
xenial/install/filesystem.squashfs "
see the screenshot below:
- error message ( http://i.imgur.com/ieucUAl.png
thanks, I'll keep track on this issue.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1571209
Title:
Sockfile check retries too short for a busy system boot
To manage notifications about this bug
@serge,
sorry for the late reply,
we live in different timezone :p
I would prefer decrease the delay time down to 1s, but keep it wait
infinitely.
according my original post (boot up with degraded RAID, 5s -> 10s), it
takes up to 10s in my case, so I don't think increasing delay from 0.5s
to 2s
** Patch added: "libvirt-bin-wily.diff"
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1571209/+attachment/4641121/+files/libvirt-bin-wily.diff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Patch added: "libvirt-bin-xenial.diff"
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1571209/+attachment/4641122/+files/libvirt-bin-xenial.diff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Patch added: "libvirt-bin-precise.diff"
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1571209/+attachment/4641119/+files/libvirt-bin-precise.diff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
@serge,
to avoid emit too much log, I've change the delay time back to "2".
@serge, @hopem,
patch files above for precise/trusty/vivid/wily/xenial have been uploaded,
should work as expected, but still, please have time to review them.
thanks !!!
** Tags added: precise vivid wily
--
You
** Patch added: "libvirt-bin-vivid.diff"
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1571209/+attachment/4641120/+files/libvirt-bin-vivid.diff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
this is the patch file from #4, but keep sleep wait time "2"
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1571209/comments/4
** Patch added: "trusty patch"
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1571209/+attachment/4641118/+files/libvirt-bin-trusty.diff
--
You
@serge,
no, I don't,
it's simply shortened the waiting time for service back or down.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1571209
Title:
Sockfile check retries too short for a busy
@serge, @hopem,
I'd like to propose a new approach, wait infinitely until the sockfile is ready,
and allow it to exit if there's an interrupt of stop/restart/force-stop event.
* excluding systemd solution, sorry I'm not familiar with systemd.
it is inspired by the following PR from Docker
Hi,
I've opened another bug/issue report, including patch, for the issue of
"libvirt-bin not start",
please see #1571209 for detail,
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1571209
it seems to the problem I've ran into, I'm wondering if it could fix your
problem,
please give
** Description changed:
[ problem description ]
- sockfile_check_retries is first introduced by #1455608, for preventing the
failure case of sockfile not ready,
- but it was default to a hard-coded value "5", it might be too short for a
busy system boot,
+ sockfile_check_retries is first
** Tags added: trusty xenial
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1571209
Title:
Sockfile check retries too short for a busy system boot
To manage notifications about this bug go to:
Public bug reported:
[ problem description ]
sockfile_check_retries is first introduced by #1455608, for preventing the
failure case of sockfile not ready,
but it was default to a hard-coded value "5", it might be too short for a busy
system boot,
#1455608 -
also hit this issue with a clean setup, but not sure how to reproduce,
since I've setup multiple server with the same "script",
but only one server hit the problem, and problem still after applying the
workaround mention in #34
here's how I setup the services,
1. apt-get install qemu-kvm
2.
thanks for update :)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ceph in Ubuntu.
https://bugs.launchpad.net/bugs/1544647
Title:
postinst syntax error, if condition without "then", and directory path
error (Ceph 9.2.0 only)
To
thanks for update :)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1544647
Title:
postinst syntax error, if condition without "then", and directory path
error (Ceph 9.2.0 only)
To manage
Hi,
the first issue, syntax error was fixed, thanks!
but the path error still there, when it is trying to setup "ceph-mds",
it says,
---
Setting up ceph-mds (9.2.0-0ubuntu5) ...
chown: cannot access ‘/var/lib/ceph/mds’: No such file or directory
dpkg: error processing package ceph-mds
Hi,
the first issue, syntax error was fixed, thanks!
but the path error still there, when it is trying to setup "ceph-mds",
it says,
---
Setting up ceph-mds (9.2.0-0ubuntu5) ...
chown: cannot access ‘/var/lib/ceph/mds’: No such file or directory
dpkg: error processing package ceph-mds
Public bug reported:
in ceph-mds.postinst,
Line 35:if ! dpkg-statoverride --list /var/lib/ceph/mds >/dev/null
Line 36:chown $SERVER_USER:$SERVER_GROUP /var/lib/ceph/mds
Line 37:fi
should be,
Line 35:if ! dpkg-statoverride --list
Public bug reported:
in ceph-mds.postinst,
Line 35:if ! dpkg-statoverride --list /var/lib/ceph/mds >/dev/null
Line 36:chown $SERVER_USER:$SERVER_GROUP /var/lib/ceph/mds
Line 37:fi
should be,
Line 35:if ! dpkg-statoverride --list
36 matches
Mail list logo
