[lxc-users] unpriviledged container failing to get an IP in Ubuntu 16

[Ivan Ogai]

Update: the error mentioned below has disappeared (was it a hardware
failure?), but the container doesn't get an IP. Doing this in the
container fixes it:

    dhclient eth0

Is this the expected behaviour? With LXC 1 (Ubuntu 16 has LXC 2), the
containers were getting an IP.

* Ivan Ogai <lxc-users at ogai.name> [2016-09-09 09:52]:
> Hello !
> 
> I sent this email yesterday to the list but I don't see it in the
> archives.
> 
> https://lists.linuxcontainers.org/pipermail/lxc-users/2016-September/thread.html
> 
> 
> Hello !
> 
> in a fresh Ubuntu 16.04 installation, when starting an unpriviledged container,
> it gets no IP (lxc-ls --fancy in the host). dmesg last lines in the container
> are:
> 
> [ 1743.140633] eth0: renamed from vethSLN6EBp
> [ 1743.180001] IPv6: ADDRCONF(NETDEV_CHANGE): vethSLN6EB: link becomes ready
> [ 1743.180205] lxcbr0: port 2(vethSLN6EB) entered forwarding state
> [ 1743.180238] lxcbr0: port 2(vethSLN6EB) entered forwarding state
> [ 1743.263802] cgroup: new mount options do not match the existing superblock, will be ignored
> [ 1758.195512] lxcbr0: port 2(vethSLN6EB) entered forwarding state
> [ 1920.142032] INFO: task systemd:6560 blocked for more than 120 seconds.
> [ 1920.142038]       Not tainted 4.4.0-36-generic #55-Ubuntu
> [ 1920.142039] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 1920.142041] systemd         D ffff8803d6acbb58     0  6560   6548 0x00000100
> [ 1920.142046]  ffff8803d6acbb58 ffff8803cfdb8dc0 ffff88042cf45280 ffff8803cfdb8dc0
> [ 1920.142049]  ffff8803d6acc000 ffff880035672088 ffff880035672070 ffffffff00000000
> [ 1920.142052]  fffffffe00000001 ffff8803d6acbb70 ffffffff81829ec5 ffff8803cfdb8dc0
> [ 1920.142055] Call Trace:
> [ 1920.142064]  [<ffffffff81829ec5>] schedule+0x35/0x80
> [ 1920.142067]  [<ffffffff8182cb12>] rwsem_down_write_failed+0x202/0x350
> [ 1920.142072]  [<ffffffff81288ff0>] ? kernfs_sop_show_options+0x40/0x40
> [ 1920.142076]  [<ffffffff813ff853>] call_rwsem_down_write_failed+0x13/0x20
> [ 1920.142078]  [<ffffffff8182c34d>] ? down_write+0x2d/0x40
> [ 1920.142081]  [<ffffffff8120fb80>] grab_super+0x30/0xa0
> [ 1920.142083]  [<ffffffff81210112>] sget_userns+0x152/0x450
> [ 1920.142085]  [<ffffffff81289070>] ? kernfs_sop_show_path+0x50/0x50
> [ 1920.142088]  [<ffffffff812892de>] kernfs_mount_ns+0x7e/0x230
> [ 1920.142092]  [<ffffffff8111858b>] cgroup_mount+0x2eb/0x7f0
> [ 1920.142094]  [<ffffffff812111d8>] mount_fs+0x38/0x160
> [ 1920.142097]  [<ffffffff8122d1d7>] vfs_kern_mount+0x67/0x110
> [ 1920.142100]  [<ffffffff8122f9a9>] do_mount+0x269/0xde0
> [ 1920.142103]  [<ffffffff8123084f>] SyS_mount+0x9f/0x100
> [ 1920.142106]  [<ffffffff8182dfb2>] entry_SYSCALL_64_fastpath+0x16/0x71
> 
> Trying to stop it in the host with "lxc-stop -n test" has no result. The
> command never finishes. This one either:
> 
>     lxc-stop -n test --kill --nolock
> 
> No log is produced with:
> 
>     lxc-stop -n test --kill --nolock -o /tmp/log -l DEBUG