1 files changed, 1 insertions, 0 deletions

diff --git a/Software/systemd/ContainerInterface.mdwn b/Software/systemd/ContainerInterface.mdwn
index c3be74e8..5138863c 100644
--- a/Software/systemd/ContainerInterface.mdwn
+++ b/Software/systemd/ContainerInterface.mdwn
@@ -13,6 +13,7 @@ systemd has a number of interfaces for interaction with container managers when
 4. udev is not available in containers (and refuses to start), and hence device dependencies are unavailable. The udev unit files will check for /sys being read-only, as an indication whether device management can work. Hence make sure to mount /sys read-only in the container (see above).
 5. If systemd detects it is run in a container it will spawn a single shell on /dev/console, and not care about VTs or multiple gettys on VTs. (But see $container_ttys below.)
 6. Either pre-mount all cgroup hierarchies in full into the container, or leave that to systemd which will do so if they are missing. Note that it is explicitly *not* OK to just mount a sub-hierarchy into the container as that is incompatible with /proc/$PID/cgroup (which lists full paths). Also the root-level cgroup directories tend to be quite different from inner directories, and that distinction matters. It is OK however, to mount the "upper" parts read-only of the hierarchies, and only allow write-access to the cgroup subtree the container runs in. It's also a good idea to mount all controller hierarchies with exception of "name=systemd" fully read-only, to protect the controllers from alteration from inside the containers. Or to turn this around: only the cgroup subtree of the container itself in the name=systemd hierarchy must be writable to the container.
+7. Create the cgroup root of container by either running your container as a service (in case you have one container manager instance per container instance) or creating one scope unit for each container instance via systemd's transient unit API (in case you have one container manager that manages all instances. Either way, make sure to set Delegate=yes in it. This ensures that that the unit you created will be part of all cgroup controllers (or at least the ones systemd understands). Make sure to use the cgroup path systemd put your process in for all operations of the container. Do not add new cgroup directories to the top of the tree. This will not only confuse systemd and the admin, but also ensure your implementation is not "stackable".
 
 ## Environment Variables
 1. To allow systemd (and other code) to identify that it is executed within a container, please set the $container= environment variable for PID 1 in the container to a short lowercase string identifying your implementation. With this in place the ConditionVirtualization= setting in unit files will work properly. Example: "container=lxc-libvirt"