Re: [lxc-users] LXC not responsive after update

[Vahid Ashrafian]

I'm having exact same problem as this on Ubuntu 14.04, lxc 1.0.8 and 1.0.7

https://lists.linuxcontainers.org/pipermail/lxc-users/2016-January/010871.html

I cannot reproduce this bug but in our many servers it happens
occasionally, specially on servers with heavy load with lots of running
threads, and after few days. Since it makes all lxc commands and as a
result all running services non-responsive we have no choice to find these
servers and force reboot them.

I wonder if there is any update on this bug.

Cheers,
Vahid
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] LXC not responsive after update

[Viktor Trojanovic]

On 28.01.2016 14:33, Andrey Repin wrote:

Greetings, Viktor Trojanovic!


Hi Bostjan,
I sent a reply with an attachment a week ago but it still was not
approved.

The reply came through to the list just fine.
https://lists.linuxcontainers.org/pipermail/lxc-users/2016-January/010862.html



Hi Andrey,

OK, my mistake, didn't see it..

I still hope anyone can make sense of my issue. The container still is 
running without problems and I don't have any immediate need to 
administer it but I'm worried what would happen in case of an 
(unintentional) reboot. Even if it would boot fine, I'd still like to 
understand where this issue is coming from and how it can be solved 
without rebooting.


Viktor
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] LXC not responsive after update

[Andrey Repin]

Greetings, Viktor Trojanovic!

>  I'm not using lxcfs, just regular directory based containers.

lxcfs is not a file system for containers.
It is a supplementary virtual FS akin to udev, if I understand it right.


-- 
With best regards,
Andrey Repin
Friday, January 22, 2016 22:01:47

Sorry for my terrible english...

___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] LXC not responsive after update

[Viktor Trojanovic]

On 20.01.2016 23:50, Fajar A. Nugraha wrote:
On Thu, Jan 21, 2016 at 5:49 AM, Fajar A. Nugraha > wrote:


On Thu, Jan 21, 2016 at 5:23 AM, Viktor Trojanovic
> wrote:

I just did a system upgrade on my Arch System which included
updating the kernel, systemd and lxc to the newest versions.
After having done so, I cannot interact with my Linux
container any longer. The system within the container still
seems to work fine and can be contacted from outside (Samba
server) but if I try to use one of the lxc commands to query
or otherwise interact with the container (e.g. lxc-ls -f,
lxc-stop, lxc-console, lxc-attach), the command hangs until I
cancel it with CTRL+C.

I get the following message when cancelling lxc-ls -f (as root):

^CTraceback (most recent call list):
  File "/usr/bin/lxc-ls", line 432, in 
containers = get_containers(root=True)
  File "user/bin/lxc-ls", line 261, in get_containers
if container.controllable:
KeyboardInterrupt

Regular lxc-ls works normal, by the way.

I can probably just reboot the server but I still wanted to
ask around if anyone has an idea why this is happening and
what I could do except rebooting to regain control of LXC? I
tried already systemctl restart lxc but that doesn't help.



Do you have lxcfs installed? If yes, this should be a know issue.
When you restart lxcfs, all existing running containers that use
it will be unable to access lxcfs-provided resources. AFAIK
restarting lxc service does restart running containers.


That should be: AFAIK restarting lxc service does *NOT *restart 
running containers.



Try killing one of those containers (lxc-stop -k -n ...), start
it, and then test again. If it works, do the same for other
containers.

-- 
Fajar




Hi Fajar,

I'm not using lxcfs, just regular directory based containers.

I cannot do anything with the containers.

lxc-stop -k
lxc-ls -f
lxc-attach
lxc-console
systemctl stop lxc (or restart lxc)

All these commands hang forever, I have to interrupt with CTRL+C and no 
output is written to the logs. But the container system keeps working 
fine, so does the host system.


Viktor

___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] LXC not responsive after update

[Bostjan Skufca]

strace command is your friend.

b.


On 21 January 2016 at 12:12, Viktor Trojanovic  wrote:

>
>
> On 20.01.2016 23:50, Fajar A. Nugraha wrote:
>
> On Thu, Jan 21, 2016 at 5:49 AM, Fajar A. Nugraha < 
> l...@fajar.net> wrote:
>
>> On Thu, Jan 21, 2016 at 5:23 AM, Viktor Trojanovic 
>> wrote:
>>
>>> I just did a system upgrade on my Arch System which included updating
>>> the kernel, systemd and lxc to the newest versions. After having done so, I
>>> cannot interact with my Linux container any longer. The system within the
>>> container still seems to work fine and can be contacted from outside (Samba
>>> server) but if I try to use one of the lxc commands to query or otherwise
>>> interact with the container (e.g. lxc-ls -f, lxc-stop, lxc-console,
>>> lxc-attach), the command hangs until I cancel it with CTRL+C.
>>>
>>> I get the following message when cancelling lxc-ls -f (as root):
>>>
>>> ^CTraceback (most recent call list):
>>>   File "/usr/bin/lxc-ls", line 432, in 
>>> containers = get_containers(root=True)
>>>   File "user/bin/lxc-ls", line 261, in get_containers
>>> if container.controllable:
>>> KeyboardInterrupt
>>>
>>> Regular lxc-ls works normal, by the way.
>>>
>>> I can probably just reboot the server but I still wanted to ask around
>>> if anyone has an idea why this is happening and what I could do except
>>> rebooting to regain control of LXC? I tried already systemctl restart lxc
>>> but that doesn't help.
>>>
>>>
>>
>> Do you have lxcfs installed? If yes, this should be a know issue. When
>> you restart lxcfs, all existing running containers that use it will be
>> unable to access lxcfs-provided resources. AFAIK restarting lxc service
>> does restart running containers.
>>
>>
> That should be: AFAIK restarting lxc service does *NOT *restart running
> containers.
>
>
> Try killing one of those containers (lxc-stop -k -n ...), start it, and
>> then test again. If it works, do the same for other containers.
>>
>> --
>> Fajar
>>
>
> Hi Fajar,
>
> I'm not using lxcfs, just regular directory based containers.
>
> I cannot do anything with the containers.
>
> lxc-stop -k
> lxc-ls -f
> lxc-attach
> lxc-console
> systemctl stop lxc (or restart lxc)
>
> All these commands hang forever, I have to interrupt with CTRL+C and no
> output is written to the logs. But the container system keeps working fine,
> so does the host system.
>
> Viktor
>
>
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] LXC not responsive after update

[Viktor Trojanovic]

Hi Bostjan,

Here is my strace to "lxc-ls -f". It looks the same with the other
commands, at least the last line is identical.

# strace -eopen lxc-ls -f
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/libpython3.5m.so.1.0", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/libutil.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No
such file or directory)
open("/usr/lib/gconv/gconv-modules", O_RDONLY|O_CLOEXEC) = 3
open("/dev/urandom", O_RDONLY|O_CLOEXEC) = 3
open("/usr/bin/pyvenv.cfg", O_RDONLY)   = -1 ENOENT (No such file or directory)
open("/usr/pyvenv.cfg", O_RDONLY)   = -1 ENOENT (No such file or directory)
open("/proc/meminfo", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/encodings/__pycache__/__init__.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/codecs.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/encodings",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/encodings/__pycache__/aliases.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/encodings/__pycache__/utf_8.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/encodings/__pycache__/latin_1.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/io.cpython-35.pyc", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/abc.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/_weakrefset.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/site.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/os.cpython-35.pyc", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/stat.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/posixpath.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/genericpath.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/_collections_abc.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/_sitebuiltins.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/sysconfig.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/_sysconfigdata.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/site-packages",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/plat-linux",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/lib-dynload",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/site-packages",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/usr/bin/lxc-ls", O_RDONLY)   = 3
open("/usr/bin/lxc-ls", O_RDONLY)   = 3
open("/usr/bin", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/argparse.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/collections/__pycache__/__init__.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/operator.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/keyword.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/heapq.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/lib-dynload/_heapq.cpython-35m-x86_64-linux-gnu.so",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/reprlib.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/copy.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/types.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/functools.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/weakref.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/collections",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/collections/__pycache__/abc.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/copyreg.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/re.cpython-35.pyc", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/sre_compile.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/sre_parse.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/sre_constants.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/textwrap.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/__pycache__/gettext.cpython-35.pyc",

Re: [lxc-users] LXC not responsive after update

[Bostjan Skufca]

Do not add -eopen argument, as it limits your view.

Do this:
- strace -f -tt -r lxc-ls -f

And while strace is running and your program is hanging, find its pid (of
lxc-ls, not strace) and run lsof -p PID (if it will be hanging on socket,
this will give you a hint what that socket is).

b.


On 21 January 2016 at 23:42, Viktor Trojanovic  wrote:

> Hi Bostjan,
>
> Here is my strace to "lxc-ls -f". It looks the same with the other
> commands, at least the last line is identical.
>
> # strace -eopen lxc-ls -f
> open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/libpython3.5m.so.1.0", O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/libutil.so.1", O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No
> such file or directory)
> open("/usr/lib/gconv/gconv-modules", O_RDONLY|O_CLOEXEC) = 3
> open("/dev/urandom", O_RDONLY|O_CLOEXEC) = 3
> open("/usr/bin/pyvenv.cfg", O_RDONLY)   = -1 ENOENT (No such file or
> directory)
> open("/usr/pyvenv.cfg", O_RDONLY)   = -1 ENOENT (No such file or
> directory)
> open("/proc/meminfo", O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/encodings/__pycache__/__init__.cpython-35.pyc",
> O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/__pycache__/codecs.cpython-35.pyc",
> O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/encodings",
> O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/encodings/__pycache__/aliases.cpython-35.pyc",
> O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/encodings/__pycache__/utf_8.cpython-35.pyc",
> O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/encodings/__pycache__/latin_1.cpython-35.pyc",
> O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/__pycache__/io.cpython-35.pyc",
> O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/__pycache__/abc.cpython-35.pyc",
> O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/__pycache__/_weakrefset.cpython-35.pyc",
> O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/__pycache__/site.cpython-35.pyc",
> O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/__pycache__/os.cpython-35.pyc",
> O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/__pycache__/stat.cpython-35.pyc",
> O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/__pycache__/posixpath.cpython-35.pyc",
> O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/__pycache__/genericpath.cpython-35.pyc",
> O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/__pycache__/_collections_abc.cpython-35.pyc",
> O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/__pycache__/_sitebuiltins.cpython-35.pyc",
> O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/__pycache__/sysconfig.cpython-35.pyc",
> O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/__pycache__/_sysconfigdata.cpython-35.pyc",
> O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/site-packages",
> O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/plat-linux",
> O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/lib-dynload",
> O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/site-packages",
> O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
> open("/usr/bin/lxc-ls", O_RDONLY)   = 3
> open("/usr/bin/lxc-ls", O_RDONLY)   = 3
> open("/usr/bin", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/__pycache__/argparse.cpython-35.pyc",
> O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/collections/__pycache__/__init__.cpython-35.pyc",
> O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/__pycache__/operator.cpython-35.pyc",
> O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/__pycache__/keyword.cpython-35.pyc",
> O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/__pycache__/heapq.cpython-35.pyc",
> O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/lib-dynload/_
> heapq.cpython-35m-x86_64-linux-gnu.so",
> O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/__pycache__/reprlib.cpython-35.pyc",
> O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/__pycache__/copy.cpython-35.pyc",
> O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/__pycache__/types.cpython-35.pyc",
> O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/__pycache__/functools.cpython-35.pyc",
> O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/__pycache__/weakref.cpython-35.pyc",
> O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/collections",
> O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
> open("/usr/lib/python3.5/collections/__pycache__/abc.cpython-35.pyc",
> O_RDONLY|O_CLOEXEC) = 3
> 

[lxc-users] LXC not responsive after update

[Viktor Trojanovic]

I just did a system upgrade on my Arch System which included updating 
the kernel, systemd and lxc to the newest versions. After having done 
so, I cannot interact with my Linux container any longer. The system 
within the container still seems to work fine and can be contacted from 
outside (Samba server) but if I try to use one of the lxc commands to 
query or otherwise interact with the container (e.g. lxc-ls -f, 
lxc-stop, lxc-console, lxc-attach), the command hangs until I cancel it 
with CTRL+C.


I get the following message when cancelling lxc-ls -f (as root):

^CTraceback (most recent call list):
  File "/usr/bin/lxc-ls", line 432, in 
containers = get_containers(root=True)
  File "user/bin/lxc-ls", line 261, in get_containers
if container.controllable:
KeyboardInterrupt

Regular lxc-ls works normal, by the way.

I can probably just reboot the server but I still wanted to ask around 
if anyone has an idea why this is happening and what I could do except 
rebooting to regain control of LXC? I tried already systemctl restart 
lxc but that doesn't help.


Cheers,
Viktor
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] LXC not responsive after update

[Fajar A. Nugraha]

On Thu, Jan 21, 2016 at 5:23 AM, Viktor Trojanovic  wrote:

> I just did a system upgrade on my Arch System which included updating the
> kernel, systemd and lxc to the newest versions. After having done so, I
> cannot interact with my Linux container any longer. The system within the
> container still seems to work fine and can be contacted from outside (Samba
> server) but if I try to use one of the lxc commands to query or otherwise
> interact with the container (e.g. lxc-ls -f, lxc-stop, lxc-console,
> lxc-attach), the command hangs until I cancel it with CTRL+C.
>
> I get the following message when cancelling lxc-ls -f (as root):
>
> ^CTraceback (most recent call list):
>   File "/usr/bin/lxc-ls", line 432, in 
> containers = get_containers(root=True)
>   File "user/bin/lxc-ls", line 261, in get_containers
> if container.controllable:
> KeyboardInterrupt
>
> Regular lxc-ls works normal, by the way.
>
> I can probably just reboot the server but I still wanted to ask around if
> anyone has an idea why this is happening and what I could do except
> rebooting to regain control of LXC? I tried already systemctl restart lxc
> but that doesn't help.
>
>

Do you have lxcfs installed? If yes, this should be a know issue. When you
restart lxcfs, all existing running containers that use it will be unable
to access lxcfs-provided resources. AFAIK restarting lxc service does
restart running containers.

Try killing one of those containers (lxc-stop -k -n ...), start it, and
then test again. If it works, do the same for other containers.

-- 
Fajar
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] LXC not responsive after update

[Fajar A. Nugraha]

On Thu, Jan 21, 2016 at 5:49 AM, Fajar A. Nugraha  wrote:

> On Thu, Jan 21, 2016 at 5:23 AM, Viktor Trojanovic 
> wrote:
>
>> I just did a system upgrade on my Arch System which included updating the
>> kernel, systemd and lxc to the newest versions. After having done so, I
>> cannot interact with my Linux container any longer. The system within the
>> container still seems to work fine and can be contacted from outside (Samba
>> server) but if I try to use one of the lxc commands to query or otherwise
>> interact with the container (e.g. lxc-ls -f, lxc-stop, lxc-console,
>> lxc-attach), the command hangs until I cancel it with CTRL+C.
>>
>> I get the following message when cancelling lxc-ls -f (as root):
>>
>> ^CTraceback (most recent call list):
>>   File "/usr/bin/lxc-ls", line 432, in 
>> containers = get_containers(root=True)
>>   File "user/bin/lxc-ls", line 261, in get_containers
>> if container.controllable:
>> KeyboardInterrupt
>>
>> Regular lxc-ls works normal, by the way.
>>
>> I can probably just reboot the server but I still wanted to ask around if
>> anyone has an idea why this is happening and what I could do except
>> rebooting to regain control of LXC? I tried already systemctl restart lxc
>> but that doesn't help.
>>
>>
>
> Do you have lxcfs installed? If yes, this should be a know issue. When you
> restart lxcfs, all existing running containers that use it will be unable
> to access lxcfs-provided resources. AFAIK restarting lxc service does
> restart running containers.
>
>
That should be: AFAIK restarting lxc service does *NOT *restart running
containers.


Try killing one of those containers (lxc-stop -k -n ...), start it, and
> then test again. If it works, do the same for other containers.
>
> --
> Fajar
>
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users