1 files changed, 2 insertions, 2 deletions

diff --git a/Software/systemd/ContainerInterface.mdwn b/Software/systemd/ContainerInterface.mdwn
index 5138863c..ad029301 100644
--- a/Software/systemd/ContainerInterface.mdwn
+++ b/Software/systemd/ContainerInterface.mdwn
@@ -13,7 +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".
+7. Create the control group root of your 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). The latter may also be done via machined's CreateMachine API. 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" 
@@ -25,7 +25,7 @@ systemd has a number of interfaces for interaction with container managers when
 2. Make the container journal available in the host, by automatically symlinking the container journal directory into the host journal directory. More precisely, link /var/log/journal/<container-machine-id> of the container into the same dir of the host. Administrators can then automatically browse all container journals (correctly interleaved) by issuing "journalctl -m". The container machine ID you can determine from /etc/machine-id in the container. 
 3. If the container manager wants to cleanly shutdown the container, it might be a good idea to send SIGRTMIN+3 to its init process. systemd will then do a clean shutdown. Note however, that only systemd understands SIGRTMIN+3 like this, this might confuse other init systems. 
 4. To support [[Socket Activated Containers|http://0pointer.de/blog/projects/socket-activated-containers.html]] the container manager should be capable of being run as a systemd service. It will then receive the sockets starting with FD 3, the number of passed FDs in $LISTEN_FDS and its PID as $LISTEN_PID. It should take these and pass them on to the container's init process, also setting $LISTEN_FDS and $LISTEN_PID (basically, it can just leave the FDs and $LISTEN_FDS untouched, but it needs to set $LISTEN_PID to for the container init process). That's all that's necessary to make socket activation work. The protocol to hand sockets from systemd to services is hence the same as from a container manager to a container systemd. For further details see the [[explanations of sd_listen_fds(1)|http://0pointer.de/public/systemd-man/sd_listen_fds.html]] and [[the blog story for service developers|http://0pointer.de/blog/projects/socket-activation.html]]. 
-5. Container managers should stay away from the "name=systemd" cgroup hierarchy. That's private property of systemd, and no other code should interfere with it. 
+5. Container managers should stay away from the "name=systemd" cgroup hierarchy outside of the unit they created for their container. That's private property of systemd, and no other code should interfere with it. 
 
 ## Networking