First of all, systemd does not depend on anything relating to how /usr is mounted. Other components don't work properly with it; it simply detects the case and

First of all, systemd does not depend on anything relating to how /usr is mounted. Other components don't work properly with it; it simply detects the case and sends a warning. systemd itself will continue to work fine, but components that systemd launches will not. It's just a messenger. I also want to note that cgroups is not the only Linux-specific interface that's necessary for systemd. There's lots of them, and if you stub all of them out, then you've achieved portability with none of the benefits, and have potentially introduced a lot of bugs. You simply make systemd runnable, but unusable. I think you have the wrong impression of cgroups entirely, though. It does not do "process monitoring". Think of it more like a hierarchical processes tree. With a traditional hierarchical filesystem, to recursively delete everything in a folder, you use a combination of readdir and unlink. In cgroups, it's similar: you put processes in a "cgroup", and to kill everything inside a "cgroup", you iterate over everything and call kill. And much like in some filesystems you can say "make sure this subtree doesn't go above 1GB of storage", you can apply similar resource limits to cgroups: "make sure this subtree doesn't go over 2GB of memory and 25% CPU time", etc. A stub interface that doesn't iterate over any of the processes won't really do you much, and thus when you try to stop a service, it won't get shut down.