Chapter 39. Linux Containers

If docker is setting up loop devices for docker thin pool setup, docker operations like docker deletion and container I/O operations can be slow. The strongly recommended alternative configuration is to set up an LVM thin pool and use it as storage back-end for docker. Instructions on setting up an LVM thin pool can be found in the lvmthin(7) manual page. Then modify the /etc/sysconfig/docker-storage file to include the following line to make use of the LVM thin pool for container storage.

DOCKER_STORAGE_OPTIONS= --storage-opt dm.thinpooldev=<pool-device>

A Super-Privileged Container (SPC) that is launched while some application containers are already active has access to the file system trees of these application containers. The file system trees reside in device mapper "thin target" devices. Since the SPC holds references on these file system trees, the docker daemon fails to clean up the "thin target" (the device is still "busy") at the time when an application container is terminated. As a consequence, the following error message is logged in the journal of systemd:

Cannot destroy container {Id}: Driver devicemapper failed to remove root filesystem {Id}: Device is Busy

where {Id} is a placeholder for the container runtime ID, and a stale device mapper "thin target" is left behind after an application container is terminated.

A Super-Privileged Container (SPC) that is launched while some application containers are already active has access to the file system trees of these application containers. The file system trees reside in device mapper "thin target" devices. Since the SPC holds references on these file system trees, the docker daemon fails to clean up the "thin target" (the device is still "busy") at the time when an application container is terminated. As a consequence, the following error message is logged in the journal of systemd:

Cannot destroy container {Id}: Driver devicemapper failed to remove root filesystem {Id}: Device is Busy

where {Id} is a placeholder for the container runtime ID, and a stale device mapper "thin target" is left behind after an application container is terminated.

The docker daemon can occasionally terminate unexpectedly while a Super-Privileged Container (SPC) is running. Consequently, a stale entry related to the Super-Privileged Container is left behind in /var/lib/docker/linkgraph.db, and the container cannot be restarted correctly afterwards.

If the GNU debugger (GDB) is executing inside a Super-Privileged Container (SPC) and attaches to a process that is running in another container on Red Hat Enterprise Linux Atomic Host, GDB does not locate the binary images of the main executable or any shared libraries loaded by the process to be debugged. As a consequence, GDB may display error messages relating to files not being present, or being present but mismatched, or GDB may seem to attach correctly but then subsequent commands may fail or display corrupted information. A workaround is to specify the sysroot and file prior to issuing the command, as follows:

set sysroot /proc/PID/root					
file /proc/PID/exe			
attach PID