This behaviour continues to exist into the 1.8 experimental releases.
We're seeing it with locale settings for far east and for Spanish.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dbconfig-common in Ubuntu.
The container has since been restarted (by issuing a 'reboot' inside the
container), which unstuck lxc-ls, it's now behaving normally. If it
happens again I'll see what I can see. It's not the first time I've seen
this happen.
LXC has not been upgraded since the container was started, no.
The
Quoting Serge Hallyn
Perhaps after a (reasonably long) timeout we should assume
it is dead, hard-kill the container (in this case the owner of the
command socket), and continue.
I'm seeing this behaviour happen in Vivid although in my case the
stuck container is perfectly responsive and is
Correction, I meant to say I'm seeing this behaviour happen in Trusty
not Vivid.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1377973
Title:
lxc-destroy/lxc-stop gets stuck
To
So if I'm reading James' comments correctly, this bug is not a little
deal. Both Akash and I have encountered this in customer environments,
and it leads to dhcpd not coming up when the interface is configured in
MAAS. This is a non-obvious failure state and subsequently leads to
several hours of
13.10 Saucy Salamander - Release
amd64 (20131016)
PackageArchitecture: all
SourcePackage: maas
UpgradeStatus: Upgraded to trusty on 2014-01-23 (8 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1274944/+subscriptions
--
Dan Poler
Sent from my
Public bug reported:
When installing MAAS, it of course acts as the DNS server for systems
under its control. However, it does not configure a DNS forwarder by
default, so when systems under its control ask for addresses about which
it does not know, it answers not found rather than forwarding
