diff options
| -rw-r--r-- | share/doc/bugs.txt | 51 |
1 files changed, 51 insertions, 0 deletions
diff --git a/share/doc/bugs.txt b/share/doc/bugs.txt new file mode 100644 index 0000000..a49f9d8 --- /dev/null +++ b/share/doc/bugs.txt @@ -0,0 +1,51 @@ +container-tools: Bugs +===================== + + +1. veth not removed on container stop +------------------------------------- + +When stopping a container, it irregularly but reproducibly happen that the +corresponding veth device of the container is not shutdown, making it +impossible to start the container again. + +This is caused by a kernel bug not cleaning up veth devices on container +collapsing. The veth device is supposed to be go away automatically after +some time, definitely after a reboot though. + +A manual workaround is to shutdown the veth device manually with: + +# ip link delete ${VETH_DEVICE} + +There is a patch for it, see for more information: +http://lists.linuxfoundation.org/pipermail/containers/2012-October/030533.html + +FIXME: add nspan message about it here + +2. bug with machine.slices etc +------------------------------ + +FIXME + +3. veth length +-------------- + +systemd creates veth devices on the fly and names them vb-$NAME, where NAME is the +container name truncated to the first 10 characters. + +Problem: if you have several containers named with the first 10 characters to be +identical, systemd will not be able to create a new veth device. + +4. root console +--------------- + +# Let's attach a console to the example container. +# +# Note: we did not create a user in the container, +# logging in as root over a pseudo-terminal is +# considered insecure by pam and will fail. +cnt console -n example.net +# Let's disable pam_securetty.so for demonstration purpose only. +vi /var/lib/machines/example.net/etc/pam.d/login +# Now login as root will work. +cnt console -n example.net |